----- Original Message -----
Miloslav Trmač <mitr(a)redhat.com> 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.
Mirek