-----BEGIN PGP SIGNED MESSAGE-----
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 (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)
> 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.
>  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
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.
>  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(a)lists.fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----