Fedora server implementation straw man

Stephen Gallagher sgallagh at redhat.com
Tue Jan 28 13:43:11 UTC 2014

Hash: SHA1

On 01/27/2014 05:41 PM, Kevin Fenzi wrote:


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

This is likely something we're going to need to write ourselves (with
an eye to getting other major distributions involved, since it will
benefit them as well).

My thought here is that what we'd probably want to do is build a
configuration service that serves a D-BUS API. The service should be
built around a plugin architecture, so that we can drop a new set of
objects onto it as part of the role package. Ideally, I'd like these
modules to be built atop something like Augeas so that we aren't
responsible for actually managing the files on-disk, just presenting
the data in the API.

I'm aware that this is non-trivial new work. If we agree that this is
what we want and need, I'm going to make an attempt at requisitioning
resources to work on it.


>>> 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'm not sure I agree with the need for additional process here, but I
am open to being convinced. For now, I'd prefer to play the
wait-and-see game and only add to this process if we see it becoming
an issue.

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

No. In many cases it only means testing a specific subset of those
dependencies. For example, FreeIPA depends on 389 DS and Dogtag, so by
your logic, testing FreeIPA is sufficient to determine that newer 389
DS and Dogtag packages work. However, there are numerous features
(particularly in Dogtag) that FreeIPA does not exercise. So I see
value in testing the packages separately from the roles.

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

Could you explain some of those reasons? To me it seems like we'd be
moving from maintaining two copies (the one in the release repo plus
the one in the updates repo) with a possibility of three or more (one
for each role that requires a unique version compared to the updates
and other role requirements).

Certainly, we should strive to ensure that this number remains 2 as
often as possible.

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

It's always difficult to determine what is a major update vs. a
compatible update that adds a few new features. I think the goal here
would be to allow compatible updates to land with the expectation that
we're going to test them with the roles and update the role packages
as soon as it's verified.


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

The other side-effect here would be to make it easy for Cloud to
implement its Cloud->Server goal (just install the
fedora-server-release package and your system now meets that condition).

Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the server mailing list