Hey,
This is my intent to reach an agreement on the best way to maintain both
the Tryton and GNU Health packages in Debian. I realize it's a long email,
but please bear with me as it is meant to be the start of a discussion.
Please speak up and argument your opinion!
========
Let me first introduce a couple of fictitious users. The goal is to
visualize how to best serve the interests of our users. Feel free to
suggest other personas if you feel this is not covering specific scenarios.
Marc: a seasoned IT-manager, he's just started to work for a start-up. He
has been tasked to come up with a system to handle the company's
accounting, invoicing, sales and purchase management. He has extensive
experience in setting up and configuring Linux-based servers, and has his
preferred way of doing things. He's got access to powerful virtual servers,
and he's got all intents of using them!
Adèle: a senior doctor working for one of the biggest hospitals in the
capital city of a developing economy, she is one of the respected voices of
her organization. Next to the patient care that takes most of her time,
she's got to handle lots of aspects of running the hospital, in particular
the transition from paper to an electronic medical record. Exciting, but
demanding times.
Luis: a cranky server admin, he was fired at the end of last year due to
economic reasons. Forced to sell his house, he has moved with his wife and
kids to live with his in-laws (which makes him even more cranky!). His
mother-in-law is a recently retired family doctor, and she still has a lot
of contacts among her former colleagues. Luis hopes to capitalize on her
connections to set up a new company aiming to provide computer services to
general practitioners in the area.
Sophie: a Business Administration student, she's excited to start her new
internship at a local department store, where she is charged of redesigning
the inventory management system in 2 months. Her success at that task will
allow her to validate her 3rd study year.
========
This is the package layout I'm suggesting, with the goal of being as
modular possible to meet all our personas' uses.
[A] database-independent server package(s)
- provides the functionality (i.e. source code)
- comes with an example start-up script, but does not install it in
/etc/init.d
- suggests the database-specific packages [B]
=> install if you want to manually configure the database, the start-up
service, etc.
[B] multiple database-specific package
- one package per supported database backend (postgres, sqlite)
- depends on the generic package [A]
- depends on one of the database backend
- uses dbconfig-common to configure the database for the user
- update process takes care of making a backup prior to upgrading, and
upgrades the database (running upstream-provided scripts, if provided).
- installs a start-up script
- question: should these be mutually exclusive with the other db-specific
package, or should both be able to live next to each other (maybe 2 servers
running on different ports?)
- idea: install a daily crontab to make automatic backups of the database
=> install if you want to have an out-of-the box working server, with
minimal configuration and maintenance
[C] one client package
- to be installed on a workstation
- wish: detects if a server is installed on the same machine
=> pretty self-explanatory: install the client if you plan to connect to
the server ;)
[D] one all-in-one package
- has the short name of the project
- depends on both the client and one database-specific package (the one
that makes most sense for a production system)
=> install if you want an out-of-the box installation combining both the
server and the client on the same machine. Focus is easy to install and
maintain.
[E] a demo package
- depends on one of the db-specific packages (same as [D], as these 2
packages must be able to live side-by-side)
- creates a separate demo database, filled with the demo data provided by
upstream
=> install to have an offline version of the demonstration data. This is
a low-priority project, but is still useful for connection-challenged
areas, or when people are often traveling without Internet connection
(think about playing around with the demo while seated in a train or plane).
========
This is how this package layout would translate for Tryton:
[A] `tryton-server`: provides the source code for the server functionality.
The current package would have to be modified to not install the start-up
service in /etc/init.d. It would provide an example configuration file,
which would need to be manually edited to fit the user's needs, and
instructions in the README.Debian file containing the steps to configure
the database (similar to current package).
Suggests: tryton-server-postgres | tryton-server-sqlite
All the different `tryton-modules-*` packages are also part of this
category: they depend on tryton-server, provide the source code for their
functionality, but don't need to care about a start-up service or
database-configuration instructions.
[B] 2 new packages would be introduced, each depending on `tryton-server`
and on one supported database backend:
- `tryton-server-postgres`
- `tryton-server-sqlite`
At installation time, the user will be prompted to configure the database
using `dbconfig-common`. The database would be created (using the default
installation of the database backend, as provided by their Debian
packagers) and prepared for use with Tryton (sudo -u <TRYTONUSER>
TRYTONPASSFILE=<PASSFILE> trytond --database=tryton --init=all
--config=<TRYTON_CONFFILE>). Database will be backed up at upgrade time,
and the database itself will be upgraded (sudo -u <TRYTONUSER> trytond
--database=tryton --update=all --config=<TRYTON_CONFFILE>)
These 2 packages install their start-up script. Goals is that using the
default configuration of the database backend, and configuring with
`dbconfig-common`, a user doesn't need to fiddle with the configuration
files (unless they want to, obviously!)
[C] The `tryton-client` package would basically stay the same as what is
currently packaged. Maybe provide a `tryton` alias?
[D] A new `tryton` package would be introduced, depending on
`tryton-client`, `tryton-server-postgres`, and a few often-used modules (or
even `tryton-modules-all`?). Once the packages are installed and the
database is configured via `dbconfig-common`, launching the Tryton client
is all that's needed to run Tryton.
[E] A new `tryton-demo` package could be created, providing the same data
as is available online at demo.tryton.org. Package would depend on
`tryton-server-postgres` and create a new database, just for the demo data.
========
This is how this package layout would translate for GNU Health:
[A] `gnuhealth-server`: bare-bones installation, depends on `tryton-server`
and the requisite Tryton modules, but does not handle anything related to
databases or start-up services (an example is provided, but not installed
in /etc/init.d).
Suggests: gnuhealth-server-postgres | gnuhealth-server-sqlite
[B] 2 new packages, both depending on `tryton-server` (i.e. not one of the
database-flavored packages) and providing GNU Health-specific start-up
service (separate port as the default Tryton installation).
- `gnuhealth-server-postgres`
- `gnuhealth-server-sqlite`
Same as for the Tryton packages of category [B], installation takes care of
creating an preparing the database, upgrades take care of backing up and
upgrading the database (also running the eventual upgrade scripts provided
by upstream)
[C] `gnuhealth-client`: depends on tryton-client, provides a wrapper that
is pre-configured for the GNU Health -specific daemon (namely: separate
port as the default Tryton installation)
[D] The `gnuhealth` package, depending on `gnuhealth-client` and
`gnuhealth-server-postgres`, is the one-stop-shop to provide an
instantaneous solution to run GNU health.
[E] A new `gnuhealth-demo` package would provide similar data as at
health.gnusolidario.org. Like `gnuhealth`, it depends on
`gnuhealth-server-postgres`.
========
Finally, going back to our personas:
Marc (the seasoned IT-manager) has set up a couple of virtual servers to
build up his ultimate ERP system:
- one running a patched version of PostgreSQL, the primary database
- a second server, identical to the first one, running Postgres in Warm
Standby/Log Shipping mode (High Availability) to replicate the primary
database in real-time. This setup provides continuous backup and short
failover times, should the primary database server experience a failure.
- another server is dedicated to run Tryton. Since the database runs on
separate servers, Marc enjoys the flexibility of installing the
`tryton-server` package and manually editing the configuration files,
pointing the database information to the remote primary Postgres server.
Adèle (the estimated doctor) was finally able to find a few hours of her
spare time to research the best options to equip her health center, and
she's selected GNU Health to present to her fellow board members. Together
with her teenage kid, they install the `gnuhealth` and `gnuhealth-demo`
packages provided by Debian, and after answering some questions (not always
very clear to the laymen), Adèle is able to give a demo to her colleagues.
After in depth sessions are held with key hospital staff, the Debian
workstation is "promoted" to a role of central server, one of the first
that is running in this important but low-resource hospital. A few
workstation are installed here and there (namely in the Emergency
Department, in the Intensive Care Unit and outside of the Operating Rooms).
Installing the `gnuhealth-client` package on these computers provides for a
quick way of setting workstations up. All in all, this new GNU Health
installation is a big step forward, but in the coming months the IT
infrastructure of the hospital will have to be beefed up!
Luis (cranky admin) has come up with a systems architecture that he hopes
will allow him to provide optimal service to the general practitioners in
his new city: on a central server, Luis has installed the
`gnuhealth-server` package, and for each customer he's set up a separate
VM, running its own database. Using Puppet, each time his mother-in-law
convinces a peer to join Luis' network, a new VM is created, together with
a separate GNU Health server dedicated for that healthcare provider. Luis
was happy to be able to inspire himself from the start-up service provided
as an example in that package, and has adapted it for his own particular
needs.
Sophie (the BA student) hasn't got much time: in less than two months, the
internship she's just started will be over! Having heard about Tryton, she
just goes for it and installs the `tryton` package that provides both the
server and the client on her laptop. After a few days reading tutorials and
playing with the online demo provided by Tryton, she's set up the roots for
a working inventory management system. Showing it off to her mentor the
next week, she's getting approval to continue on that path and enter all
the department store's inventory in that new system. At the end of her
internship, one of the idle servers of the company is used to install
`tryton-server-postgres`, the data is migrated from the laptop to this new
server, and the head of the department gets a fresh install of the
`tryton-client` package on her desktop. Mission accomplished!
========
So, this is where the discussion continues: what do you think of my
proposal for the package layout for both Tryton and GNU Health?
Anything that crosses your mind when reading the made-up scenarios? I tried
to make them realistic, but we all know the world out there is much more
complex. Providing only 4 examples will obviously not cover all use-cases,
but by trying to make it a bit less abstract, I hope we can make this a
productive discussion and find the best solution in the long run.
I am willing to help out (if needed) in packaging Tryton.
For me the most important is that we reach an agreement ;)
Cheers,
+Emilien
