Stephen Gallagher <sgallagh(a)redhat.com> writes:
On 06/02/2014 02:51 AM, Marius Vollmer wrote:
>
> What is "active", exactly? Is it the same as state ==
"started"?
>
IIRC, we're defining "active" as "we've deployed the role on this
system". That could mean "deployed but not currently started". It
might also mean "We've installed the role but have not yet configured
it".
Would it be possible to explain "active" in terms of the operations on
roles? For example, a role becomes "active" after a successful
"deploy", and "decommission" causes a role to no longer be
"active".
>> org.fedoraproject.ServerRoleManager1.roles.$n
>
> What is the $n here? Is it the version of the interface? (If we
> specify a concrete API, we just need one name. Role specific APIs
> should be separate interfaces on the same object.)
I think it's supposed to be the role name, but Thomas can correct me.
So: org.fedoraproject.ServerRoleManager1.roles.DomainController or
org.fedoraproject.ServerRoleManager1.roles.DatabaseServer
But we don't define those interfaces here, no? We only define the
generic one that every role should support, and we just need one
concrete name for it. org.fedoraproject.ServerRoleManager1.Role?
> What is the state before the role is deployed?
Good point, we probably need "unconfigured".
So "deploy" goes from "unconfigured" to "deployed"? Did you
mean
"undeployed"?
Sorry for being pedantic, but IMO defining the states is not trivial,
and a major part of the API. So let's not hand wave them away now and
treat them as a random string that we can easily change later. :-)
> Changing state is not instantanous. Can I see when a role is
> currently being deployed (and how long that is still estimated to
> take)?
Estimating the deployment time is out of scope (we probably won't
realistically know the answer).
Having "deploying" and "starting" states would be a good idea,
though.
A common approach would be to export "Job" objects on D-Bus that carry
progress information and have a Cancel method. "deploy" would return
the path of such an object.
> What does "configured" mean? It's not the same as
"active" or
> "started", right? Can I start a unconfigured role? Could this be
> a state?
A "configured" Role can be in any of "deployed",
"starting", "started"
or "dead" states.
In what states can a "unconfigured" role be? Maybe "unconfigured"
can
be a state.
> How can I cancel?
Cancellation isn't currently supported (in part because we don't
presently have a guarantee that installing Roles can reasonably be
rolled back).
Hmm, users will always find a way to cancel even without an explicit
button, so roles need to be prepared for that anyway, I'd say.
I don't want to have a cancellation routine without a guaranteed
clean-up. This is something we may be able to address with managing
Roles in containers, though.
I think interrupting yum is well defined, no?
>> reconfigureRole(a{sv}) # reconfgure role with new config
settings as
>> key value pairs
>
> A role could specific which program to run to do a interactive
> configuration. For terminal, for a graphical session, and for
> Cockpit (by specifying a module that Cockpit will load).
Out of scope. We don't want the API to be interactive to that level.
It introduces too much complexity.
The API will be pretty much static, so the UIs should be able to just
do whatever interaction they want and then push down the final
results.
Sure, I was actually going in the other direction, but I wasn't clear:
_Instead_ of reconfigureRole (which can't be used generically), the
generic role description would just say what program to run for a
limited number of session types. FreeIPA would say "ipa-server-install"
here, and Cockpit would offer to run that in a terminal.
The state of the role would tell when it is legal to run that program.
Any configuration APIs should be on the role specific interfaces such as
org.fedoraproject.ServerRoleManager1.Role.DomainController, no?