Role States

Wed Jun 4 14:03:47 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/2014 04:40 AM, Marius Vollmer wrote:
> 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.
> 

I don't think we want a "half-installed" state. It's either installed
or not.

> 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.
> 

I see the states from the role manager as being:

Not installed -> Installed -> Configuring -> Ready

> 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.
> 

The decommission operation should not uninstall packages. This would
be unsafe (the classic situation when trying to delete a yum group).

> [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.
> 

I've actually been thinking that we might want to treat Role
activation as a systemd *target*, rather than a unit file. We can set
up which service and socket units are relevant to meet that target.

I'm not sure if systemd allows us to query from the target which
services are associated with it though. I'll need to look into that.

>> 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...
> 

A failed "deploy" could theoretically leave the system in either the
Installed or Not Installed states, depending on whether it got past
the package installation step.

A failed update should probably leave the system in just an
"Unexpected Error" state.