CentOS virt - Jan 2015 - SIG repo layout and conflicts between projects within a SIG

At the moment, we're essentially using yum repos as the "patch"
mechanism to CentOS Base: SIGs populate a repo with packages they want
to add / override, and all other packages default to Base.

The current setup is that every sig has exactly one production repo
per CentOS version.

Also, we seem to be wanting to see SIGs not as individual projects,
but to make the 'G' an actual "group": so, for instance, the
Virt SIG
has both Xen and Docker, and we've recently approved oVirt.

But there's a bit of a conflict here: what if one project in the SIG
wants to use the package from Base, and another project in the SIG
wants to use a custom-built package?  Or what if both projects want to
customize their packages in different ways?

In particular: the Docker project in the Virt SIG wants to supply
updated versions of Docker; but at the moment uses the kernel package
from Base.  The Xen project, on the other hand, needs to supply a
different kernel package that has dom0 support enabled.

Up until this point, this hasn't been an issue because I've been doing
Xen development in virt6-testing, and Lokesh has been doing Docker
development in virt7-testing.  But I'm hoping to get Xen for CentOS 7
out soon, and I was just about to upload the Xen kernel to the CBS,
when it occurred to me that if I did so, then everyone using the
virt7-testing repo for Docker would suddenly get my updated kernel as
well.

So it seems we have a couple of ways to approach it.

1. Keep it one repo per SIG, and make all projects in a SIG sort out
shared dependencies.

2. Allow one repo per *project* within a SIG (e.g., virt6-xen, virt7-docker)

3. Have some alternate way of doing a "patch", instead of repos.

In the case of xen / docker, I haven't talked with Lokesh about this
at all; it may be that he's fine with sharing a kernel with Xen.  But
it does increase the workload: now Lokesh needs to maintain the Docker
side of the kernel, whereas before they could just rely on our
upstream to do a lot of that testing.  Furthermore, it increases the
complexity of development and testing: before when doing kernel work,
I could just test Xen; now the kernel needs to be tested by both Xen
and Docker.  And finally, now users of both projects get a kernel
update whenever either one does.

Which, of course, is pretty much the same as any other distro; but as
a whole, at the moment at least, we have a lot less resources than any
other distro our size and popularity.

On the whole I'm inclined to prefer #2.

Thoughts?

 -George

On Mon, 2015-01-19 at 12:08 +0000, George Dunlap wrote:
> ...
> 
> The current setup is that every sig has exactly one production repo
> per CentOS version.
> 
> ...
> 
> So it seems we have a couple of ways to approach it.
> 
> 1. Keep it one repo per SIG, and make all projects in a SIG sort out
> shared dependencies.
> 
> 2. Allow one repo per *project* within a SIG (e.g., virt6-xen,
virt7-docker)
> 
> 3. Have some alternate way of doing a "patch", instead of repos.
> 
> ...
> 
> On the whole I'm inclined to prefer #2.
> 
> ...
  I vote for #2, as well.

  Though I'm not actively participating in pushing new releases, I'm
interested because I've got 18 servers currently running CentOS 5 with
Xen.  I'm concerned about stability of future Xen support in CentOS if
there are too many chefs touching the packages with the complexity of
juggling all the virtualization flavors.

Il 19/01/2015 18:19, Edward L Heron ha scritto:
> On Mon, 2015-01-19 at 12:08 +0000, George Dunlap wrote:
>> ...
>>
>> The current setup is that every sig has exactly one production repo
>> per CentOS version.
>>
>> ...
>>
>> So it seems we have a couple of ways to approach it.
>>
>> 1. Keep it one repo per SIG, and make all projects in a SIG sort out
>> shared dependencies.
>>
>> 2. Allow one repo per *project* within a SIG (e.g., virt6-xen,
virt7-docker)
>>
>> 3. Have some alternate way of doing a "patch", instead of
repos.
>>
>> ...
>>
>> On the whole I'm inclined to prefer #2.
>>
>> ...
> 
>   I vote for #2, as well.
> 
I vote #2 as well. It would ease the maintenance of the repo.



>   Though I'm not actively participating in pushing new releases,
I'm
> interested because I've got 18 servers currently running CentOS 5 with
> Xen.  I'm concerned about stability of future Xen support in CentOS if
> there are too many chefs touching the packages with the complexity of
> juggling all the virtualization flavors.
> 
> 
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> http://lists.centos.org/mailman/listinfo/centos-virt
> 

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com