----- Original Message -----
> deploy(a{sv}) # deploy role (i.e. running initial
setup
> # post-package-install, ipa-server-install)
> # with the given parameters in key value
> # pairs in a dictionary, these parameters
> should be
> # saved in the role configuration setings by
> # the role after successful deployment
As a generic client that wants to discover and deploy roles, how do I
determine the parameters?
It’s probably not reasonable to have a generic client
with zero knowledge about what is being deployed (if you “deploy PostgreSQL with no
information given”, would it be localhost-only or internet-facing?). Something or someone
needs to know about that specific role.
Though, it should be possible to have a generic _software_ with zero knowledge about what
is being deployed (e.g. anaconda/puppet deploying a role when given a role-specific,
knowledge-containing configuration file). That would also imply that it would be _highly
desirable_ to provide an One and Only implementation for parsing the configuration file
into the required a{sv} format.
> STARTED = "started"
> RUNNING = "running"
What's the difference between these two? A description of the states
would be helpful.
Actually, many of the states are rather different from the diagram Stephen sent earlier.
Has this been redesigned?
> ERROR = "error"
I guess an interactive client will want to offer different actions
depending on the state of a role. For example, when the state is
"nascent", it would offer to deplpy the role, but not to "start" it.
When it is "ready-to-start" or "stopped", it would offer to start
it.
Etc.
What should it offer in the "error" state? Nothing?
Per the (now invalid?) proposal in the ”Server Role States” thread, the Error state is
only reachable for already deployed roles; failure to deploy gets you back to Nascent.
Mirek