Role States

[Thomas Woerner]

What are the needed and wanted role states?

It was requested to have integer states. A bit field maybe? Questions 
and suggestions welcome.

Please add roles with a description:

Role              | Description
------------------+----------------------------------------------------------------
enabled           | Role will be started automatically at next boot
configured        | Configuration has been added
deployed          | Role is deployed
activation_failed | Activation (with systemd) failed
                   |

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

Is there a need for time stamps for these states?

[Miloslav Trmač]

2014-06-03 17:30 GMT+02:00 Thomas Woerner <twoerner(a)redhat.com&gt;:

>  What are the needed and wanted role states?
>
>  It was requested to have integer states. A bit field maybe? Questions and
>  suggestions welcome.
>  
I'd much rather see a state transition diagram (expecting that many of the
N×N theoretical state transitions wouldn’t actually be possible).

Please add roles with a description:
>  Role              | Description
>  ------------------+-----------------------------------------
>  -----------------------
>  enabled           | Role will be started automatically at next boot
>  configured        | Configuration has been added
>  deployed          | Role is deployed
>  
I’d rather collapse these two: what does “deploy” of an unconfigured role
even mean, and how can I configure something that hasn‘t been deployed?

activation_failed | Activation (with systemd) failed
>  
Do we need to be *that* specific?  Perhaps just “failed”
meaning
“successfully deployed but not working”?

Is there a need for time stamps for these states?
>  
Not timestamps, no.  But there is a need to have an
user-accessible log,
and having it machine-parsable would be even better.
    Mirek

[Marius Vollmer]

Thomas Woerner <twoerner(a)redhat.com&gt; 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...

[Stephen Gallagher]

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

On 06/04/2014 04:40 AM, Marius Vollmer wrote:
>  Thomas Woerner <twoerner(a)redhat.com&gt; 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.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlOPJ0MACgkQeiVVYja6o6MqWACgpmlvu+cmGnBRYkY0yE+C6hUR
> c4YAoK5mZ7oZ6OqmgAZDNORv4l/zWk2u
> =149S
> -----END PGP SIGNATURE-----

[Marius Vollmer]

Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:

>  I don't think we want a "half-installed" state.
> It's either installed
>  or not. 
I agree.  I had it in an earlier draft of the mail and forgot to remove
this reference to it when I removed the state.

> > 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). 
I see.  (That's my ignorance showing, I didn't want to specify what
decommission really should do.)

>  A failed update should probably leave the system in just an
>  "Unexpected Error" state. 
Yep.  This all reminds me of a previous life:

    https://maemo.gitorious.org/maemo-af/apt-desktop/

We had a "broken" state there for packages that have unsatisfied
dependencies or other problems.  If we have such a state, a failed
"deployed" might just as well end up in it.