Re: Please review control and templates for tryton-server
* Justin B Rye: " Re: Please review control and templates for tryton-server"
(Wed, 14 Sep 2022 14:21:44 +0100):
> Mathias Behrle wrote:
> >> I'm starting with comments on the templates and hoping to work up
> >> towards MRs later - first I might need some help with understanding
> >> them.
> >
> > Just tell me if you want to do MRs or if I should merge your proposed
> > changes along the discussion.
>
> It would take me a long time to work out the right git commands, so if
> you're happy with diffs then I'll stick with them.
That's perfect, I will merge the changes myself.
Just as a tipp: you don't need any knowledge to ptopose MRs on
salsa.debian.org. You can just select files like
https://salsa.debian.org/tryton-team/tryton-server/-/blob/debian-bullseye-6.0/debian/tryton-server-all-in-one.templates
and then choose "Open in Web IDE". After editing you push "Create commit" and
salsa will make by default a new MR of your changes.
> >>> Template: tryton-server-uwsgi/enable-cron
> >>
> >> (Somehow I've ended up doing these in slightly jumbled order.)
> >>
> >>> Type: boolean
> >>> Default: false
> >>> _Description: Configure cron for the Tryton server?
> >>
> >> The template name implies that the choice isn't whether they should be
> >> left uncustomised, it's whether they should run at all. So:
> >>
> >> _Description: Set up Tryton server cron jobs?
> >
> > Indeed the Tryton server cron runs separately from the main server and it is
> > this process that is set up. It is comparable to the system cron, but
> > handles internally scheduled jobs for Tryton. So 'Set up Tryton server cron
> > jobs?' is misleading, because the individual cron jobs have to be
> > configured/activated separately in each database. Perhaps 'Set up a Tryton
> > server cron process?'
>
> In fact I would have said it isn't a *cron* process at all; to me,
> "cron" means the system cron daemon, /usr/sbin/cron, whereas this is
> some Tryton subsystem that has been unhelpfully given the same name,
> rather as if it called its internal logging daemon "rsyslogd".
I understand your concern, but there are several cron implementations, and they
are all task schedulers.
> Looking it up I see that doing it this way lets Tryton store scheduled
> tasks as database entries. The documentation says:
> # Tryton provides a scheduler (aka cron) which can execute methods of
> # models periodically at set intervals.
Exactly.
> >>> There exist several Tryton server cron jobs that mainly run periodically
> >>> some maintenance tasks on the database. They can be configured with the
> >>> clients.
> >>
> >> Tryton server has several cron jobs that can be activated to perform
> >> periodic maintenance on the database. They can be configured using the
> >> Tryton clients.
> >
> > Perfect.
>
> It might be if we were actually talking about cron jobs; since we
> aren't it should say something like
>
> Template: tryton-server-uwsgi/enable-cron
> Type: boolean
> Default: false
> _Description: Enable the Tryton scheduler?
> Tryton server has its own "cron" scheduler which can run periodic
> database-maintenance tasks (configured using the Tryton clients).
> Please specify whether it should be activated.
Sounds good!
> >> (I may be misinterpreting the second sentence.)
> >>> .
> >>> Note: Only one cron server should be enabled per database.
> >>
> >> Wait, is it really talking about Tryton running its own cron-daemon
> >> *server*? That also seems to be what the package description implies,
> >> but why on earth would anybody want to do that? (Is it maybe some
> >> misleadingly named task-scheduling subprocess of the Tryton server?)
> >> I'm going to assume for now that this should be something like
> >>
> >> Note: Only one maintenance cron job should be enabled per database.
> >>
> >> But maybe this is the kind of instruction that belongs in whatever
> >> interface is going to be used to pick the ones that will run?
> >
> > It is indeed only one cron server that should be started per database.
> > Otherwise tasks will run twice or conflict and interfere with each other.
>
> I still don't understand it, then. This template is asking whether or
> not a single thing should be activated; it doesn't give the user any
> way of enabling more than one scheduler. So what advice is this note
> trying to give me?
The package could be installed in different containers that refer to the same
database (e.g. load balancing). The cron should only run once per database.
> >>> Template: tryton-server-postgresql/db-admin-email
> [...]
> >>> Template: tryton-server-uwsgi/enable-workers
> [...]
> >
> >>> If workers are configured those tasks (like e.g. the processing of sales,
> >>> invoices or purchases) can be automatically performed by workers. They
> >>> do not wait for completion in the clients thus removing the need of
> >>> waiting and doing serialized steps.
> >>
> >> Well, obviously not waiting eliminates some waiting, but it's not
> >> quite clear what's going on with the serialised steps... maybe:
> >>
> >> If enabled, the workers can automatically perform tasks such as the
> >> processing of sales, invoices, or purchases without waiting for the
> >> clients to finish, thus removing the need for serialisation.
> >
> > The serialized steps are mostly workflow steps that when called manually
> > take some time to complete. Pushing those tasks to a worker doesn't block
> > the client until the process has finished but allows to continue almost
> > immediately. The serialized process is just handled by another process.
>
> All in all I think it's clearer if it just stops at "without waiting
> for the clients to finish". For a start it hides the fact that I
> mis-localised "serialisation".
Ok.
> >>> Template: tryton-server-all-in-one/postal-code-countries
> >>> Type: multiselect
> >>> Choices: Afghanistan - AF, Albania - AL, Algeria - DZ, American Samoa -
> >>> AS,
> [...]
> >>> Yemen - YE, Zambia - ZM, Zimbabwe - ZW, Åland Islands - AX
> >>
> >> Should all these get translations using the "__Choices" mechanism?
> >
> > No, I don't think so.
> >
> >> (Sorted from A to Å by official name, with the UK and Ukraine
> >> confusingly using GB and UA? Oh well, I probably can't fix that.)
> >
> > There was some discussion about the best format for this list. And yes, we
> > can't fix ISO country codes... ;)
>
> Well, there's always the hope that one of them will disintegrate, and
> it doesn't look as if it's going to be UA.
>
> [...]
> >> I nearly missed the package descriptions in the control file! The
> >> content looks mostly good, though the short descriptions need work
> >> and there's some inconsistent capitalisation - no time to go through
> >> commenting now, I'll just attach a first-draft modified version.
>
> Going through the diff:
> > --- control 2022-09-14 12:15:34.570732971 +0100
> > +++ control.jbr 2022-09-14 12:18:18.027995351 +0100
> > @@ -67,7 +67,7 @@
> > tryton-modules-all,
> > tryton-server-doc
> > Provides: ${API}
> > -Description: Tryton Application Platform (Server)
> > +Description: Tryton application platform - server
>
> I'm making the synopses lowercase apart from the word "Tryton"
> (keeping caps on "Tryton Application Platform" would also be
> justifiable) and then using a dash instead of parentheses just because
> that's the d-l-e standard style.
>
> Likewise for:
> > -Description: Tryton Application Platform (Server Documentation)
> > +Description: Tryton application platform - server documentation
>
> (There is client documentation somewhere too, right?)
>
> [...]
> > -Description: Tryton Application Platform (Tryton Server PostgreSQL)
> > +Description: Tryton application platform - PostgreSQL integration
> [...]
> > -Description: Tryton Application Platform (Tryton Server uWSGI)
> > +Description: Tryton application platform - uWSGI integration
I would prefer for the moment to keep caps on Tryton Application Platform.
For the rest I will have to go through all modules for uniform formatting.
> (Or maybe s/integration/backend/? But I haven't changed that in this
> revised diff.)
>
> > Tryton is a high-level general purpose application platform. It is the
> > base of a complete business solution as well as a comprehensive health and
> > hospital information system (GNUHealth).
> > .
> > For production use it is recommended to run the Tryton server under a
> > - wsgi backend instead of the simple werkzeug development server.
> > + WSGI backend instead of the simple werkzeug development server.
>
> (I've never been sure if there's a difference between running a server
> *under* a backend and running it *on top of* a backend...)
The requests go to the backend which delivers them to the server. For me the
server runs under a backend (but that could be German speak...).
>
> Oh, and isn't it Werkzeug? Especially given that it *started* with
> German Noun-Capitalisation...
I would follow the project name here: https://github.com/pallets/werkzeug
> > - This package provides the integration of tryton-server with the uwsgi
> > backend.
> > + This package provides the integration of tryton-server with the uWSGI
> > backend.
>
> (I gather the u is for micro, but they've never written it as μ.)
The project itself doesn't use the μ, so do I.
> > It offers also the possibility to configure and run workers and/or cron as
> > uWSGI daemons.
>
> My revised version makes this
>
> It also offers the possibility of configuring and running workers and/or
> the scheduler as uWSGI daemons.
What about:
It also offers the possibility of configuring and running workers and/or
the internal scheduler as uWSGI daemons.
> > The Tryton server can be accessed by the uWSGI and/or the HTTP protocol.
>
> Even assuming it really means "HTTP" and not "HTTP(S)" this is probably
> plural protocols:
>
> The Tryton server can be accessed by the uWSGI and/or HTTP protocols.
Ok. It means indeed HTTP, for HTTPS the nginx frontend should be preferably
used.
> > - For small sites that are not exposed to the internet this may already
> > cover
> > - your needs, otherwise have a look at package tryton-server-nginx to run
> > + For small sites that are not exposed to the Internet this may already
> > cover
> > + your needs; otherwise have a look at the package tryton-server-nginx to
> > run the uWSGI server behind a dedicated reverse proxy.
> >
> [...]
> > -Description: Tryton Application Platform (Tryton Server Nginx)
> > +Description: Tryton application platform - Nginx integration
>
> (Again: s/integration/backend/?)
integration is better.
> > Tryton is a high-level general purpose application platform. It is the
> > base of a complete business solution as well as a comprehensive health and
> > hospital information system (GNUHealth).
> > .
> > - While the uWSGI server as WSGI backend offers the possibility to serve
> > http
> > + While the uWSGI server as WSGI backend offers the possibility to serve
> > HTTP content it is still preferable to expose the content produced by the
> > Tryton
> > - server via https with a dedicated web frontend like Nginx on top of a
> > - robust wsgi application.
> > + server via HTTPS with a dedicated web frontend like Nginx on top of a
> > + robust WSGI application.
> > Nginx has decent default security settings, is able to talk to WSGI
> > - applications by the native WSGI protocol and also offers features like
> > + applications by the native WSGI protocol, and also offers features like
> > caching of dynamic content, load balancing, serving static resources.
>
> That's mostly just fixing the capitalisation; here's a slightly more
> rephrased version:
>
> While the uWSGI server as WSGI backend offers the possibility of serving
> HTTP content it is still preferable to expose the content produced by the
> Tryton server via HTTPS with a dedicated web frontend like Nginx on top of
> a robust WSGI application. Nginx has decent default security settings, can
> talk to WSGI applications by the native WSGI protocol, and also offers
> features like caching of dynamic content, load balancing, and serving
> static resources.
>
> (Does "serving static resources" really count as a "feature"?)
The feature is the *fast* serving, indeed.
> [...]
> > -Description: Tryton Application Platform (Tryton Server All In One)
> > +Description: Tryton application platform - metapackage
>
> Assuming it *is* a metapackage... if it's full of setup wizards maybe
> it should be something like
> Description: Tryton application platform - full installation
That's better, I will have to think about this.
> > Tryton is a high-level general purpose application platform. It is the
> > base of a complete business solution as well as a comprehensive health and
> > hospital information system (GNUHealth).
> > @@ -180,8 +180,8 @@
> > Tryton server installation.
> > It will provide
> > - the guided configuration and creation of the PostgreSQL database
> > - - the guided setup of an uWSGI backend
> > - - the guided setup of a nginx frontend with the optional registration
> > + - the guided setup of a uWSGI backend
> > + - the guided setup of an Nginx frontend with the optional registration
> > and setup of Letsencrypt certificates
> > - a preconfigured PostgreSQL database prefilled with static data
> > - like countries, currencies and postal codes ready for use
> > + such as countries, currencies, and postal codes ready for use
>
> Again this is mostly just recapitalised; but looking at it again I
> find myself asking questions like "how do you configure something
> before you've created it?" and "what's the difference between
> guided configuration and guided setup?". Oh, and it's either
> "letsencrypt" or "Let's Encrypt". Revised version:
>
> [...] Tryton server installation. It provides
> * guided creation of the PostgreSQL database;
> * guided setup of a uWSGI backend;
> * guided setup of an Nginx frontend with the optional registration and
> setup of Let's Encrypt certificates;
> * a preconfigured PostgreSQL database prefilled with static data such as
> countries, currencies, and postal codes ready for use.
Thank you so far!
I will merge the changes and propose the final results to you.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Reply to: