2014-06-03 9:19 GMT+02:00 Marius Vollmer <marius.vollmer@redhat.com>:
Stephen Gallagher <sgallagh@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.