Open Stack

On 7/31/15, 07:40, "Jesse Pretorius" <jesse.pretorius at gmail.com> wrote:

>I'm adding openstack-operators too as this is a discussion that I think
>it would be useful to have their input for.

I've removed them from the CC since I don't think we're supposed to
cross-post.

>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?
> 

So, I'm not proposing that yaprt be updated to forcibly add epochs or
anything else. What yaprt will generate is exactly what upstream
specifies. For example, glance would be version 11.0.0, nova would be
12.0.0, etc.

Giving a more concrete example (which I should have done in the original
message):

If we're upgrading Glance in the containers, we'll be upgrading from

glance==2015.1.0 (obviously not exactly that, but for the sake of this
example bear with me)

To 

glance==11.0.0

And we'll use the version that yaprt reports to do

# pip install glance==11.0.0

So the repositories that we build can have both 2015.1.0 and 11.0.0 in it
and pip will always install 11.0.0.

This allows for

1. In-place upgrades
2. Reproducibility
3. Stability
4. Side-stepping upstream refusing to use epochs

>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.

Yeah, this could be held onto for a single cycle, certainly, but it is
really just good practice at this point given the volatility we should be
expecting from upstream versioning at this point. If we're going to go
back and forth between versioning schemes without epochs because they're
ugly, we may as well simply always pin the version we're installing in
containers. It has the same effect as we previously had by building local
repositories and always installing the latest (which was always the
version we most recently built). This means that we meed to read the yaprt
report (which is JSON and will be trivial) and incorporate its information
into our service-specific roles. It should be as low impact as I can
imagine an upgrade-specific change like this being.

Does that make sense?

Cheers,
Ian