2014-06-03 13:55 GMT+02:00 Stephen Gallagher <sgallagh@redhat.com>:
On 06/03/2014 07:39 AM, Miloslav Trmač wrote:
> 2014-05-30 17:35 GMT+02:00 Thomas Woerner <twoerner@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