-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
[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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlOXFEgACgkQeiVVYja6o6NgjgCfdl3/ZOlUU4BUaUtMp4apkdGb
54wAn3+f1iuG+omWrOPfrHxNEsWEtwjS
=pn9o
-----END PGP SIGNATURE-----