Open Stack

On 12/2/2015 2:33 PM, Jeremy Stanley wrote:
> [Apologies for the delayed reply, after more than a week without
> Internet access it's taking me more than a week to catch up with
> everything on the mailing lists.]
>
> On 2015-11-20 10:21:47 +0000 (+0000), Kuvaja, Erno wrote:
> [...]
>> So we were brainstorming this with Rocky the other night. Would
>> this be possible to do by following:
>>
>> 1) we still tag juno EOL in few days time
>
> Hopefully by the end of this week, once I finish making sure I'm up
> to speed on everything that's been said while I was out (anything
> less would be irresponsible of me).
>
>> 2) we do not remove the stable/juno branch
>
> As pointed out later in this thread by Alan, it's technically
> possible to use a tag instead of a branch name (after all, both are
> just Git refs in the end), and deleting the branch sends a clearer
> message that there are no new commits coming for stable/juno ever
> again.
>
>> 3) we run periodic grenade jobs for kilo
>>
>> I'm not that familiar with the grenade job itself so I'm doing
>> couple of assumptions, please correct me if I'm wrong.
>>
>> 1) We could do this with py27 only
>
> Our Grenade jobs are only using Python 2.7 anyway.
>
>> 2) We could do this with Ubuntu 1404 only
>
> That's the only place we run Grenade now that stable/icehouse is EOL
> (it was the last branch for which we supported Ubuntu 12.04).
>
>> If this is doable would we need anything special for these jobs in
>> infra point of view or can we just schedule these jobs from the
>> pool running our other jobs as well?
>>
>> If so is there still "quiet" slots on the infra utilization so
>> that we would not be needing extra resources poured in for this?
>>
>> Is there something else we would need to consider in QA/infra
>> point of view?
> [...]
>
> There are no technical Infra-side blockers to changing how we've
> done this in the past and instead continuing to run stable/kilo
> Grenade jobs for some indeterminate period after stable/juno is
> dead, but it's also not (entirely) up to Infra to decide this. I
> defer to the Grenade maintainers and QA team to make this
> determination, and they seem to be pretty heavily against the idea.
>
>> Big question ref the 2), what can we do if the grenade starts
>> failing? In theory we won't be merging anything to kilo that
>> _should_ cause this and we definitely will not be merging anything
>> to Juno to fix these issues anymore. How much maintenance those
>> grenade jobs themselves needs?
>
> That's the kicker. As I explained earlier in the thread from which
> this one split, keeping Juno-era DevStack and Tempest and all the
> bits on which they rely working in our CI without being able to make
> any modifications to them is intractable (mainly because of the
> potential for behavior changes in transitive dependencies not under
> our control):
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081109.html
>
>> So all in all, is the cost doing above too much to get indicator
>> that tells us when Juno --> Kilo upgrade is not doable anymore?
>
> Yes. This is how we arrived at the EOL timeline for stable/juno in
> the first place: gauging our ability to keep running things like
> DevStack and Tempest on it. Now is not the time to discuss how we
> can keep Juno on some semblance of life support (that discussion
> concluded more than a year ago), it's time for discussing what we
> can implement in Mitaka so we have more reasonable options for
> keeping the stable/mitaka branch healthy a year from now.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I agree with Jeremy. We might be able to consider something like this 
for stable/liberty, since that's when we started doing 
upper-constraints, which should make the dependency creep more manageable.

-- 

Thanks,

Matt Riedemann