Server Role States

[Stephen Gallagher]

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

On 06/11/2014 10:15 PM, Simo Sorce wrote:
> On Tue, 2014-06-10 at 10:20 -0400, Stephen Gallagher wrote:
>> Thomas Woerner, Miloslav Trmač and I had a long discussion the
>> other day about how to handle states in the Role API. We came up
>> with the following approach:
>> 
>> Persistent States: Nascent[1] (We know about the Role but have
>> not attempted to deploy it) ReadyToStart (It has been installed
>> and configured but is not running) Running (Self-explanatory) 
>> Error (Something has gone wrong and needs to be corrected to
>> return the system to ReadyToStart[2])
>> 
>> Transitional States (used to indicate that other clients should
>> not interfere): Deploying Decommissioning Starting Stopping
>> 
>> I've attached a graphviz document and a rendered PNG of the
>> state diagram to hopefully make it clear. Comments and feedback
>> welcome, but our intent is to be off and implementing before the
>> end of the week.
>> 
>> 
>> [1] While we were discussing this, we had "Known, not deployed"
>> as a placeholder here. I think "nascent" covers this elegantly,
>> but if others have a better idea, the name is not set in stone.
> 
> I find it hard to grok 'Nascent', aren't 'Available' or
> 'Deployable' better terms ?

I didn't like "Available" because to me it implies something similar
to ReadyToStart. Deployable is an option.

I picked nascent because of its definition:
"adj. just coming into existence and beginning to display signs of
future potential"
This seemed like *exactly* what this state is.


> Also ReadyToStart sound a bit long on my tongue, why not just 
> 'Deployed', or even simply 'Ready' ? Otherwise if ReadyToStart is
> good, why not also ReadyToDeploy (instead of Nascent).
> 

"Ready" implies to me that some action has already been taken.

> Sorry to bikeshed :/
> 

Ultimately, these are just terms and will be documented with their
full meanings, so as long as they meet the "good enough" metric, let's
not waste much more time on them.

> Simo.
> 
>> [2] There will be two ways to recover from the Error state. The
>> client can call deploy() again and fix the issue, or they can
>> call resetError() which will short-cut to ReadyToStart. This is
>> how they can proceed if they choose to fix the error with manual
>> edits that the API doesn't understand. resetError() should be a
>> last resort. _______________________________________________ 
>> server mailing list server at lists.fedoraproject.org 
>> https://admin.fedoraproject.org/mailman/listinfo/server
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOZssgACgkQeiVVYja6o6N+LACgkPq+ffJ43f+ssBMJX1me7M8R
YwAAnRPq6k4ahGxk+jh7efyj2M0ssYuV
=BSJk
-----END PGP SIGNATURE-----