On Tue, 28 Jan 2014 08:43:11 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
This is likely something we're going to need to write ourselves
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.
Yeah, it sounds like it could be a lot of work, but it could also be
potentially a very good value add.
In the end we always need to keep in mind: why would someone install
the fedora server freeipa role instead of just installing the packages
and configuring it themselves as they do now? We need to make it
compelling to use the role. :)
>>> 6. We setup specific bodhi requirements (like critpath)
>>> 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
Sure, this could definitely be something we push off for now, but
adjust as we get closer to some kind of alpha release.
>> I think it's fine for the individual *packages* to
>> 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.
Sure, again, I think both are good.
>> This has impact on Fedora Infrastructure, as it will mean
>> 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
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).
So, the way composes work now is that bodhi calls mash and mash calls
out to koji and says "hey, give me the latest package tagged into this
tag" and then it composes say 'fedora/20/updates' repo from that.
If you wanted to keep more than the latest, we would have to call out
for 'give me all packages in the tag, and then figure out which are
the latest two (or whatever) and compose that'. Which is a great deal
more intensive and error prone. You have to think of things like epoch
Getting past that, the other big hurdle is mirrors. "Hey, you know
that 1TB of fedora you have? We are going to make it 2 or 3, hope
Getting back to the orig statement, why wouldn't we just not push a
version to stable until it meets the requirements of the role?
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.
We should be able to use updates-testing for this, no?
new version enters updates-testing -> we test with role, update role
and push it's new version into updates-testing (preferably with the
same update as the new package so they go stable at the same time).
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