On Mon, 27 Jan 2014 14:29:02 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
Ok, so aside from the monitoring/backup stuff you list below, the
primary purpose of this role package is to drop whatever is needed on
the system in order to produce the API that Cockpit will consume to
set up the configuration? (Or, in the more rare cases where a
reasonable default exists, drop that default on the system and go)?
Yeah. As well as making sure all the parts needed for the role are
installed.
> 1 A way to express what items should be monitored when the role
is
> installed/running. Perhaps /etc/server/$role/monitoring/ports and
> processes and such.
We really need to come up with a clearer definition of "monitor" here.
What exactly does /etc/server/$role/monitoring/ports mean? Just a set
of ports that have to be accessible publicly for it to be considered
working? I assume we'd also be including firewalld configuration as
part of the role API so that we can handle that properly.
Yeah. There may be some upstream work somewhere we could reuse here.
Some kind of generic monitoring spec that monitoring solutions could
consume? Anyone know of anything in this space?
> 2 A way to express data that should be backed up if you want to
> backup the role. Perhaps /etc/server/$role/backups/datadirs and
> configdirs or databases.
>
> 3. We may want to change systemd presets to indicate things that
> should be running/enabled/etc when the role package is installed.
>
As mentioned above, this should generally be done when Cockpit (or
other management tool) *deploys* the role. It should only be done by
the package if it meets the "may be packaged in such a way that it can
be uninstalled as a complete unit" Conditional Requirement[1]
Sure. There's going to be some cases of things you don't want to start
on boot until configured, etc.
> 4. Anything else we need to impement an "API" for
roles. Are we
> going to define this soon?
Yes, we need to have a breakout session somewhere to start working
this out. My suggestion would be for us to standardize on something
that is already available on the system (to avoid growing new
dependencies). My suggestion would be for us to build a D-BUS service,
since that will be easily consumed by Cockpit, OpenLMI and many
languages.
So, this would be a thing that looked at all the config put down in
the role rpm and published it and changes over dbus for any consumers?
We are writing this? Or is there something generic we can reuse with
our needed config?
> 5. We can tie this package to specific versions of
requirements.
> So, for example, if there's a new freeipa update and we haven't
> valided fedora-server-freeipa with it, the requirement can be on
> the older version and the users will not be updated until we push
> an update to this package.
>
I'm going to suggest that *can* has to be *must* (within a certain
reasonable level). I.e. we should probably allow the release number to
change without forcing the role package to be regenerated.
E.g.
Requires mydep >= 1.2.2
Conflicts mydep >= 1.3
as opposed to:
Requires mydep == 1.2.2-1
Sure, we could do that. The goal there would be to stop someone from
accidentally upgrading past our tested versions.
> 6. We setup specific bodhi requirements (like critpath) for
server
> role packages, requiring specific testing before they can go
> stable.
>
I'd *really* like for us to be testing things holistically, rather
than individually. It's probably not enough for us to just check "Is
this in a role package? Yes: require more testing".
Sure, I think we should do that _also_
This would just be a way to catch things like "hey, freeipa is bumping
a major release in a stable version" (just an example)
I think it's fine for the individual *packages* to continue in
the
process that they are now. However, in order to bring something into
the *role*, we should have to test it as a complete system.
Sure, since the role package requires specific things tho, doesn't
testing it also mean testing those?
This has impact on Fedora Infrastructure, as it will mean that we
will
need to retain multiple (non-parallel-installable) versions of
packages in the repositories, since we will always need to be able to
satisfy the role requirements (which may be older than the upstream
package).
This is difficult for a number of reasons. :) (Not impossible, but
difficult).
However, we should always have the initial version at release.
And we should be able to stop a new version in testing that breaks
things/is a major version bump, no? We don't want to be pushing major
updates into stable releases...
Now, I'd be in favor of implementing something like the CRITPATH
process (possibly even the old style, requiring a proventester) for
updating the role package alone. There are two reasons for this:
1) Having the role package installed is a pretty clear indication that
you are actually trying to use the role holistically.
2) It encourages a more comprehensive set of system tests as opposed
to package tests (since people will be testing how the role works,
specifically.
Sure.
...snip...
It's off-topic, but I would like to see us also build a
fedora-server-release package that does much the same: allows us to
identify the minimum set of stuff that we call "Fedora Server" and if
you want to remove some pieces of it, you can... but you're no longer
building atop our tested platform.
Yeah, might be worth doing...
kevin