<div dir="ltr">I'm adding openstack-operators too as this is a discussion that I think it would be useful to have their input for.<br><div class="gmail_extra"><br><div class="gmail_quote">On 30 July 2015 at 19:18, Ian Cordasco <span dir="ltr"><<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey all,<br>
<br>
As you may have seen elsewhere on openstack-dev, OpenStack is changing the<br>
versioning for the service projects. This means our previous upgrade<br>
solution will not continue to work. For context, one of our project's<br>
goals is to have in-place upgrades be a reality. Previously, using our<br>
repository (package) mirror doing:<br>
<br>
    # pip install -U {{servicename}}<br>
<br>
Was perfectly fine. The problem will now occur that 2015.1.0 (kilo) is<br>
more recent than any of the new service version numbers (as far as pip is<br>
concerned). This would be resolved if the release management team for<br>
OpenStack properly used an epoch to indicate that the versioning scheme is<br>
fundamentally different and something like Glance 8.0.0 should sort after<br>
Glance 2015.1.0, but they won't (for reasons that you can read in earlier<br>
threads on this list).<br></blockquote><div><br></div><div>Yes. This is going to cause quite a few headaches I'm sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, in order to satisfy the goal of in-place upgrades, we need a way<br>
around this. Currently, we use a tool called 'yaprt' to build wheels and<br>
repository indices for our project. This tool can (and currently does)<br>
create reports of the built files and exports those reports as JSON. We<br>
can use this to know the version generated for a service and then instead<br>
do:<br>
<br>
    # pip install {{servicename}}=={{yaprt_generated_version}}<br>
<br>
This will force pip to ignore the fact that the existing (kilo)<br>
installation is actually supposed to sort as more recent because you're<br>
telling it to install a very specific version. This will likely need to be<br>
our upgrade path going forward unless we also require operators to clear<br>
out their existing repository mirror of packages with Kilo versions (and<br>
then we can go back to relying on pip's version sorting semantics to do<br>
pip install -U {{servicename}}).<br></blockquote><div><br></div><div>So what would the resulting version be? Would the python wheel be 2016.x.x or would the file simply be named that so that we're sitting with this workaround for only one cycle and future cycles can revert to the previous process?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is, at the moment, the seemingly simplest way to work around the<br>
brokenness that is the upstream versioning change.<br>
<br>
If you can think of a different way of approaching this, we'd love to hear<br>
it. If not, Kevin or myself will probably start working on this approach<br>
in a week or two so it's ready for when Liberty is actually released and<br>
we can start testing upgrades from the kilo branch to master (which is<br>
currently tracking liberty).<br></blockquote><div><br></div><div>This is not a fun problem to have to solve, but it seems a reasonable solution. Whatever we do I'd prefer to see it as a solution that we only have to carry for one cycle so that all versioning matches upstream from then on. If that's not possible then some sort of epoch-style workaround like this may just be something we have to live with. </div></div>
</div></div>