Fedora server implementation straw man

[Kevin Fenzi]

On Tue, 28 Jan 2014 08:43:11 -0500
Stephen Gallagher <sgallagh at redhat.com> wrote:
 
> 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.

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

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

Sure, again, I think both are good. 

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

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
changes, etc. 

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
thats ok"

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

...snip...

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

Yep. 

kevin
-------------- 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/20140129/ad66dc45/attachment.sig>