On 02/04/2014 04:02 PM, Jim Perrin wrote: >> Look at it this way, putting glusterfs, ceph in tier3 ( 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. > > But openshift would be able to exist as a tier 1 or tier2, since it's > simply adding packages without updating core distro rpms. So it depends > a bit on what the user wants to do. maybe it needs puppet, which needs ruby which comes from a repo that replaces the base os ruby. So while it can exist as a tier1 in this model, its dep tree is going to cascade upto tier3, so might as well make it a tier3 repo. > > So the issue seems to be more with the dependency tiering requirement > rather than the categorization of the tiers themselves. yes, we need stuff to go into the lower tiers that have the ability to change packages, so that other repos can then rely on them ( or require them optionally, eg: opennebula-node-xen ) > >> 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. > > > They can't be tier1's if they're updating or conflicting with existing > packages, but we can certainly relax the dependency requirements to > resolve this. That should resolve this issue, right? or we find a way to have repos contain content that overwrites others, and use namespace overload or something other mechanism to allow it at any tier. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc