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 ?
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).
Sorry to bikeshed :/
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
--
Simo Sorce * Red Hat, Inc * New York