[CentOS-devel] Repository structures for SIG and variants in the future

Sun Feb 2 20:46:21 UTC 2014
Karanbir Singh <mail-lists at karan.org>


On 01/13/2014 07:05 PM, Jim Perrin wrote:
>  - Tier 3 repositories: These repositories contain packages that
> conflict with software inside the core distribution. This would be
> Xen4CentOS for example, which replaces the kernel, and adds in xen
> functionality.

at fosdem we've tried to flesh out how this might work with some real
world examples, and unfortunately this model will not work.

The actual structure and layers needs to be much simpler with dependancy
allowed as you mentioned ( ie. tier 1 can only rely on itself and OS,
tier2 can rely on itseld + one or more tier1's + os, tier3 can rely on
itself + one or more tier2's, one or more tier1's and os ).

Look at it this way, putting glusterfs, ceph ( bcause they need a
modified build for qemu ) will mean that the only way openstack is able
to consume it will be if openstack is in the same repo ( and they are
all collected at a teir3 ), then cascade down and the entire dep tree
needs to move back upto a teir3, at which point its all just a flat OS
tree and tier3 repos.

So with that in mind, i think repo's should be allowed to exist at any
tier, with a repo being able to decide for itself if it wants to include
content that replaces functionality + adds, or just adds. ie. adopt the
Extras/ and Plus/ seperation ( with Plus/ automatically -required- to
include Extras/ ) at each tier.

nutshell: libvirt, qemu, xen4centos, ceph and friends are all going to
be -required- to be tier1's and be allowed to replace ( namespace
overload ?) components, so that every other component above in other
teri1's or 2's or 3's are able to consume it.

Also, I think we should explore the idea ( or atleast have the option )
of shipping an app lxc container instead of a SCL; Overall, we just need
to find a better way to (a) build + deliver them (b) build relationships
and (c) consume common metadata from the instance / container host. We
might go down the route of using the container delivery mechanism within
the VOIP SIG ( proposal for that coming soon... )

Anyone fancy writing a yum plugin to ship and manage conainers ? Only
partially joking...

- KB

Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc