Fedora server implementation straw man

Kevin Fenzi kevin at scrye.com
Mon Jan 27 22:41:28 UTC 2014

On Mon, 27 Jan 2014 14:29:02 -0500
Stephen Gallagher <sgallagh at 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

> > 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

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.


> 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... 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140127/105898cb/attachment.sig>

More information about the server mailing list