Role States

[Marius Vollmer]

Thomas Woerner <twoerner at redhat.com> writes:

> What are the needed and wanted role states?

Disclaimer:

I haven't participated in the earlier discussions about Server Roles,
and I can already see that I am missing a lot here.  I don't want to
reopen discussions that have already happened with my ignorance, so
please just tell me "Shut up, you don't know what we are talking about"
and I'll happily do that...

Ok, what about this:

The ServerRoleManager only reprents the state of roles as far as they
pertain to installation and configuration, up to a point where systemd
can take over and do its thing.

I don't know the fine points of configuration and deployment, but maybe
something like this:

not-installed:   Not all of the packages are fully installed.

not-configured:  The packages are fully ainstalled, the unit files are
                 on the system and systemd knows about them, but
                 starting a unit is known to fail with a "not yet
                 configured" error.

ready:           The unit files are ready to be started.

The "deploy" operation aims to move a role into the "ready" state.  This
is done by installing packages, configuring the firewall, and dropping a
configuration snippet if it is know.  If that fails, the role ends up in
"half-installed".  If there is no configuration snippet but one is
needed, the role ends up in the "not-configured" state.

Or something like this with whatever intermediate states we need between
"not-installed" and "ready" to make configuration work.  Most roles will
hopefully be able to go from not-installed to ready in a single step.

Once in "ready" state, the client of ServerRoleManager is supposed to
dig out the unit names, and talk to systemd to get them started.

The "decommission" operation undoes the firewall configuration and
removes the packages, without checking the run-time state of the units.
That is the responsibility of the client.

[1] We might recommend to only have one unit file, and that unit file
represents the run-time state of the role.  With multiple unit files, we
would have multiple run-time states for a role.  Not a dramatic
difference, but multiple unit files might be a hint that a role should
be split.

> Do we need failed states like for example activation_failed or
> deploy_failed?

I think a failed "deploy" can leave the role in the "not-installed"
state.  However, a failed "upate" is interesting...