Proposal for the Server Role API

[Miloslav Trmač]

2014-06-03 9:19 GMT+02:00 Marius Vollmer <marius.vollmer at redhat.com>:

> Stephen Gallagher <sgallagh at redhat.com> writes:
>
> > On 06/02/2014 02:51 AM, Marius Vollmer wrote:
> >>> 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.
>

Nonononono.  You might just as well define that IPA.defineRole is
equivalent to (ipa-server-install $the_value_of_param_a
$the_value_of_param_b), and so on for every operation, ship an XML file
with these definitions (and perhaps one more file for X/Wayland UIs if
anything provided them), and drop the D-Bus API completely, then.

I think we do want the API to be used generically, by tools that *can* be
generic.  E.g. store the role configs in a configuration management system
as files, and have exactly the same D-Bus call (or command-line utility) to
deploy them, perhaps in the shell-script world something like

for f in /etc/our-site-role-configs/*; do server-role deploy
> --kickstart-like $f; done
>

Good UI can’t be generic and I basically don’t think we can avoid writing a
Cockpit-and-roles-specific UI if we want any non-CLI UI at all.  (i.e.,
cockpit-specific but not-roles-specific wouldn‘t work at all, and
roles-specific but not-cockpit-specific mostly wouldn’t work either).

Overall, I think Stephen’s proposal to let the operations accept a
fully-prepared configuration (like the a{sv} above), is a reasonable
approach at the API level.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140603/ecfb98a0/attachment.html>