Open Stack

On 12/02/2015 04:11 PM, Matt Riedemann wrote:
> 
> 
> 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.

However, only if there are enough active QA contributors / reviewers to
keep up on this. Which means anyone interested in this needs to start
engaging and ramping up on Tempest / Devstack / Grenade on master *now*.

People showing up the month before eol, and only focussing on the eoled
elements is not productive.

	-Sean

-- 
Sean Dague
http://dague.net