2014-06-03 13:55 GMT+02:00 Stephen Gallagher <sgallagh(a)redhat.com>:
On 06/03/2014 07:39 AM, Miloslav Trmač wrote:
> 2014-05-30 17:35 GMT+02:00 Thomas Woerner <twoerner(a)redhat.com
> <mailto:twoerner@redhat.com>>:
> org.fedoraproject.ServerRoleManager1.roles.$n
> ------------------------------__---------------
version:s (ro) # role version
> Version /of what/? Of a role-specific API, of the implementation of
> the role, of the underlying upstream project, of the persistent
> data format?
The implementation of the role, which includes the role-specific API
and persistent data format.
How would the caller map from role version 5 to role API 3 and persistent
data format 2? (“We’re not doing that for the first version” is quite
acceptable, I just want to be clear about the semantics.)
> deploy() # deploy role (i.e. running initial
setup
> post-package-install, ipa-server-install)
>
> How is interactivity, non-interactive kickstart-like deployment,
> error handling done?
No interactivity. You give it all the necessary data, then watch the
Job for completion.
OK; then how did I give it the data, and how do I watch the job?
> start() # start the role (startServices,
> installFirewall), fails if not deployed stop() #
> stop the role (stopServices, uninstallFirewall), fails if not
> started
>
> Does this have persistent effect (survive reboot)?
I'd say make that an input value, default to persistent.
I should have said this right away: It seems to me we actually only need
the persistent version. Non-persistence is just not that useful,
especially considering the corner cases like sudden power loss reverting
your configuration.
updateRole() # update role: yum update;
> restartServices; updateFirewall
>
> If the update requires more information from the user (even if just
> to confirm a non-reversible data migration), how is interactivity
> and non-interactive kickstart-like deployment done?
Given the nature of open-source projects, the only safe assumption is
that *every* updateRole includes a non-reversible data migration.
I don’t think it’s that bad even in Fedora (though it *would* make our
earlier discussions about more coordinated upstream server/role updates
more critical), and for RHEL and the like it’s going to be very much the
rare case. (At least assuming that updateRole() would be called for ~every
package update, not only when upgrading to a new major version.)
> reconfigureRole(a{sv}) # reconfgure role with new config
settings
> as key value pairs
>
> How do I get the full set of current settings to submit to this
> call?
They are exposed as the * properties of the role object.
Can I enumerate them? (In a way that doesn't include things like
“activate_time”.) IMHO this *should* be possible to do generically
(fedora-server save-state ipa > foo.xml) without knowledge of the
particular role.
installPackages() # install packages and groups
> #uninstallPackages() # uninstall packages and groups, fails if
> deployed - not initially
>
> The caller managing the server doesn‘t need to know that; this is
> an implementation detail of the role.
Doesn't need to know what?
Anything about packages; the caller should just say “install postgres” and
never hear about RPMs. (Notably, this would allow us to *transparently*
switch from RPMs to Docker images—and even back the other way if
necessary.)
startServices() # start the services restartServices()
> # restart the services stopServices() # stop the
> services
>
> The caller managing the server doesn‘t need to know that; this is
> an implementation detail of the role.
Same question.
Same answer: just say “start postgres” and never hear about systemd units.
Especially when there *already* is start() and stop(), exposing the
subcomponents of that API is rather redundant.
(Separately: In the internal implementation, should the API talk about all
systemd unit types, or only services, BTW? I’m thinking about socket units
in particular.)
Mirek