[openstack-dev] [openstack-ansible] [os-ansible-deployment] Kilo -> Liberty Upgrade Problems

Ian Cordasco ian.cordasco at RACKSPACE.COM
Thu Jul 30 18:18:20 UTC 2015


Hey all,

As you may have seen elsewhere on openstack-dev, OpenStack is changing the
versioning for the service projects. This means our previous upgrade
solution will not continue to work. For context, one of our project's
goals is to have in-place upgrades be a reality. Previously, using our
repository (package) mirror doing:

    # pip install -U {{servicename}}

Was perfectly fine. The problem will now occur that 2015.1.0 (kilo) is
more recent than any of the new service version numbers (as far as pip is
concerned). This would be resolved if the release management team for
OpenStack properly used an epoch to indicate that the versioning scheme is
fundamentally different and something like Glance 8.0.0 should sort after
Glance 2015.1.0, but they won't (for reasons that you can read in earlier
threads on this list).

So, in order to satisfy the goal of in-place upgrades, we need a way
around this. Currently, we use a tool called 'yaprt' to build wheels and
repository indices for our project. This tool can (and currently does)
create reports of the built files and exports those reports as JSON. We
can use this to know the version generated for a service and then instead
do:

    # pip install {{servicename}}=={{yaprt_generated_version}}

This will force pip to ignore the fact that the existing (kilo)
installation is actually supposed to sort as more recent because you're
telling it to install a very specific version. This will likely need to be
our upgrade path going forward unless we also require operators to clear
out their existing repository mirror of packages with Kilo versions (and
then we can go back to relying on pip's version sorting semantics to do
pip install -U {{servicename}}).

This is, at the moment, the seemingly simplest way to work around the
brokenness that is the upstream versioning change.

If you can think of a different way of approaching this, we'd love to hear
it. If not, Kevin or myself will probably start working on this approach
in a week or two so it's ready for when Liberty is actually released and
we can start testing upgrades from the kilo branch to master (which is
currently tracking liberty).

Cheers,
Ian



More information about the OpenStack-dev mailing list