[Rdo-list] Glance packaging and RDO Kilo
dprince at redhat.com
Mon Apr 20 13:01:00 UTC 2015
On Mon, 2015-04-20 at 12:12 +0200, Alan Pevec wrote:
> Moving discussion to rdo-list
> > I have spent some time during the weekend thinking about the options here.
> > Looking at the requirements from all parties, I see the following:
> > a) From the packaging side, we want to split Glance into several packages (glance,-common,-api and -registry).
> > b) From the deployment side, we want the glance package to behave as it did before, i.e. pull -api and -registry.
> > c) From the puppet-glance side, if we have separate -api and -registry packages, we want to reflect that change in the Puppet modules and be able to configure -api and -registry independently. Also, this package split is already happening in Debian/Ubuntu, so removing distro-specific code is always welcome.
> > With that in mind, I think the following options as the easiest ones to implement:
> > 1- Split packages, with the following deps:
> > * -api and -registry depend on -common
> > * glance depends on -api and -registry
> > This would require moving the existing content in glance (/usr/bin/glance-manage and /usr/bin/glance-control) into -common, so glance becomes a meta-package. With this, we would get b) and c), and most of a). The only drawback is that glance-manage and glance-control may not be a good fit for the -common package (Haikel, can you comment on this?). FWIW, this is how it is being packaged today in Debian.
> > 2- Keep the old situation (no Glance package split)
> > This obviously negates a), and keeps distro-specific code in c), but still works and does not break any existing code.
> > Any thoughts?
> > Regards,
> > Javier
> Thanks for the summary Javier, 1) is the right thing to do. For the
> record, history of this change was:
> * https://review.gerrithub.io/229724 - Split openstack-glance into new
> * https://review.gerrithub.io/229980 - Backward compatiblity with
> previous all-in-one main package (quickfix after I've seen Packstack
> failures, in retrospect that were I should've introduced -common with
> glance-manage as you propose)
> ** in the meantime, puppet-glance was adjusted to take advantage of
> the subpackages: https://review.openstack.org/172440 - Separate api
> and registry packages for Red Hat
> * https://review.gerrithub.io/230356 - Revert dependencies between
> services and the main packages (followup, b/c after puppet-glance
> change glance-manage was not getting installed)
> * https://review.gerrithub.io/230453 - Revert "Split openstack-glance
> into new subpackage" (merged to unblock tripleo)
> ** https://review.openstack.org/174872 - Revert "Separate api and
> registry packages for Red Hat" in puppet-glance
> So the plan is to re-propose "Split openstack-glance into new
> subpackages" and merged only after it's verified by all interested
> teams and then re-propose "Separate api and registry packages for Red
> Hat" in puppet-glance.
If we do the package split correctly there should be no rush to go and
update puppet-glance or any of the configuration tools out there. I
would actually suggest waiting a bit to modify puppet-glance to prove
the new packaging split works with the old puppet-glance implementation
(perhaps filing a bug on this so we don't forget when to do it). If we
do it this way then someone who wants to selectively use an older Glance
package could still do so with the upstream Glance modules.
>From an end user prospective I don't think there isn't a lot of value in
this split. I mean don't get me wrong, I wish we would have split out
glance-registry 4 years ago. I just don't see why there is all of a
sudden a rush to split it now, especially considering that
glance-registry would eventually get deprecated anyway?
Regardless, so long as we do the split in such a manner as it doesn't
functionally break users who upgrade (this is the most important thing)
I think it is probably okay. We should just make sure that during this
split we test all the cases where this package may actually get used. I
would like to see the split package working with the (old) puppet-glance
modules and the existing TripleO image elements as well. If it works in
both of those locations it is probably fine. This may involve manual
testing time as we don't yet have RDO trunk CI on all these packaging
More information about the dev