Proposal for the Server Role API

[Miloslav Trmač]

2014-06-03 13:55 GMT+02:00 Stephen Gallagher <sgallagh at redhat.com>:

> On 06/03/2014 07:39 AM, Miloslav Trmač wrote:
> > 2014-05-30 17:35 GMT+02:00 Thomas Woerner <twoerner at redhat.com
> > <mailto:twoerner at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140603/d1a9ace4/attachment.html>