-----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(a)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-----