rolekit D-Bus API v2

Miloslav Trmač mitr at
Wed Jul 2 13:15:33 UTC 2014

----- Original Message -----
> Miloslav Trmač <mitr at> writes:
> > It’s probably not reasonable to have a generic client with zero
> > knowledge about what is being deployed (if you “deploy PostgreSQL with
> > no information given”, would it be localhost-only or
> > internet-facing?).  Something or someone needs to know about that
> > specific role.
> Yeah, but that "something" could be installed together with the rest of
> the role during deployment, no?

That “something” can be a person, not something to install :)

You’re right that there are in principle various stages:
1. only role name known
2. role configuration documentation or specialized UI available
3. role configured, ready to start
4. role running 

We are currently calling 3 “deployed” and both 1 and 2 “nascent”, i.e. not making a distinction between the two.  Cockpit may well need to know about the difference between 1 and 2, but I don’t think the user needs to know—when the user asks cockpit to deploy some role that is currently in 1, cockpit should transition to 2 transparently without asking.  The 1->2 transition may need to be a rolekit facility, but then we end up with rolekit implicitly knowing about the existence of cockpit and a dependencly loop (which is a bit ugly but might nevertheless be the right thing to do).

For now I think we should be perfectly fine just pre-installing all specialized UIs by default.

> Doing configuration after deployment (and not as part of it), has its
> own issues, so I am happy to sit back and see how this unfolds. :)

The way I think about it, only the user-visible activities really count; so “deployment” is an activity that involves user input or interaction.  Any kind of package installation or file modifications necessary to make the “deployment” actually happen is invisible enough that we can shuffle it around arbitrarily (e.g. packagees default installed / installed exactly when needed / predictively installed based on Facebook posts / whatever), as long as the user interaction model is maintained.

So, configuration in a sense _is_ deployment.  Getting the necessary packages to the server is an invisible activity that might just as well not exist (e.g. because we just preinstall all servers).

> > That would also imply that it would be _highly desirable_ to provide
> > an One and Only implementation for parsing the configuration file into
> > the required a{sv} format.
> Here are five dollars that say that people will just happily use
> dictionaries like
>    { "/etc/foo.conf": "<contents of /etc/foo.conf>",
>      "/etc/bar.conf": "<contents of /etc/bar.conf>"
>    }
> I know I would. :-)

Oh yes.  And here are five dollars that say that if we allow any two different programs (e.g. rolekit and puppet) to implement the text->dictionary parsing it will end up different in a way that affects semantics.

More information about the server mailing list