On 02/04/2014 06:00 PM, Karanbir Singh wrote:
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.
Yum priority= fits so nicely here. Just saying.