Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Wednesday, December 02, 2015 8:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> [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 + (+), 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.
> --
> Jeremy Stanley

Thanks for two detailed reply Jeremy!

I think this (and the one you replied to Rocky) gives enough background in 
compact package for interested parties to start focusing their efforts to the 
direction they seem appropriate. Let's see where we are in a year's time.

- Erno

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Sean Dague]

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 + (+), 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-requ...@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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Jeremy Stanley]

[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 + (+), 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.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Matt Riedemann]

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 + (+), 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-requ...@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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Alan Pevec [mailto:ape...@gmail.com]
> Sent: Friday, November 20, 2015 10:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> > 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
> > 2) we do not remove the stable/juno branch
> 
> Why not?
> 
> > 3) we run periodic grenade jobs for kilo
> 
> From a quick look, grenade should work with a juno-eol tag instead of
> stable/juno, it's just a git reference.
> "Zombie" Juno->Kilo grenade job would need to set
> BASE_DEVSTACK_BRANCH=juno-eol and for devstack all
> $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be the same commit).
> Maybe I'm missing some corner case in devstack where stable/* is assumed
> but if so that should be fixed anyway.
> Leaving branch around is a bad message, it implies there support for it, while
> there is not.
> 
> Cheers,
> Alan

That sounds like an easy compromise.

- Erno
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

> 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
> 2) we do not remove the stable/juno branch

Why not?

> 3) we run periodic grenade jobs for kilo

>From a quick look, grenade should work with a juno-eol tag instead of
stable/juno, it's just a git reference.
"Zombie" Juno->Kilo grenade job would need to set BASE_DEVSTACK_BRANCH=juno-eol
and for devstack all $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be
the same commit).
Maybe I'm missing some corner case in devstack where stable/* is
assumed but if so that should be fixed anyway.
Leaving branch around is a bad message, it implies there support for
it, while there is not.

Cheers,
Alan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Friday, November 20, 2015 10:45 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> 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
> > 2) we do not remove the stable/juno branch
> > 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
> > 2) We could do this with Ubuntu 1404 only
> >
> > 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?
> >
> > Benefits for this approach:
> > 1) The upgrade to kilo would be still tested occasionally.
> > 2) Less work for setting up the jobs as we do the installs from the
> > stable branch currently (vs. installing the last from tarball)
> >
> > What we should have as requirements for doing this:
> > 1) Someone making the changes to the jobs so that the grenade job gets
> ran periodically.
> > 2) Someone looking after these jobs.
> > 3) Criteria for stop doing this, X failed runs, some set timeperiod,
> > something else. (and removing the stable/juno branch)
> >
> > 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?
> >
> > 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?
> 
> Let's wait a bit for this discussion for the return of the Infra PTL from
> vacation, his input is critical to any decision we can make. Jeremy should be
> back on Monday.
> 
> --
> Thierry Carrez (ttx)

Sure, didn't know that he is on holidays, but there was a reason why I added 
infra and qa tags to the subject. Like you said infra being able to facilitate 
this is crucial for any plans.

- Erno
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Sean Dague]

On 11/20/2015 06:01 AM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Alan Pevec [mailto:ape...@gmail.com]
>> Sent: Friday, November 20, 2015 10:46 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
>> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
>>
>>> 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
>>> 2) we do not remove the stable/juno branch
>>
>> Why not?
>>
>>> 3) we run periodic grenade jobs for kilo
>>
>> From a quick look, grenade should work with a juno-eol tag instead of
>> stable/juno, it's just a git reference.
>> "Zombie" Juno->Kilo grenade job would need to set
>> BASE_DEVSTACK_BRANCH=juno-eol and for devstack all
>> $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be the same commit).
>> Maybe I'm missing some corner case in devstack where stable/* is assumed
>> but if so that should be fixed anyway.
>> Leaving branch around is a bad message, it implies there support for it, 
>> while
>> there is not.
>>
>> Cheers,
>> Alan
> 
> That sounds like an easy compromise.

Before doing that thing, do you regularly look into grenade failures to
determine root cause?

Because a periodic job that fails and isn't looked at, is just a waste
of resources. And from past experience very very few people look at
these job results.

-Sean


-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Thierry Carrez]

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
> 2) we do not remove the stable/juno branch
> 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
> 2) We could do this with Ubuntu 1404 only
> 
> 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?
> 
> Benefits for this approach:
> 1) The upgrade to kilo would be still tested occasionally.
> 2) Less work for setting up the jobs as we do the installs from the stable 
> branch currently (vs. installing the last from tarball)
> 
> What we should have as requirements for doing this:
> 1) Someone making the changes to the jobs so that the grenade job gets ran 
> periodically.
> 2) Someone looking after these jobs.
> 3) Criteria for stop doing this, X failed runs, some set timeperiod, 
> something else. (and removing the stable/juno branch)
> 
> 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?
> 
> 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?

Let's wait a bit for this discussion for the return of the Infra PTL
from vacation, his input is critical to any decision we can make. Jeremy
should be back on Monday.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Tuesday, November 17, 2015 2:57 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
> [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> 
> 
> On 11/16/2015 8:49 PM, Rochelle Grober wrote:
> > I would like to make a plea that while Juno is locked down so as no changes
> can be made against it, the branch remains on the git.openstack.org site.
> Please?  One area that could be better investigated with the branch in place
> is upgrade.  Kilo will continue to get patches, as will Liberty, so an 
> occasional
> grenade run (once a week?  more often?  Less often) could help operators
> understand what is in store for them when they finally can upgrade from
> Juno.  Yes, it will require occasional resources for the run, but I think 
> this is
> one of the cheapest forms of insurance in support of the installed base of
> users, before a Stable Release team is put together.
> >
> > My $.02
> >
> > --Rocky
> >
> >> -Original Message-
> >> From: Gary Kotton [mailto:gkot...@vmware.com]
> >> Sent: Friday, November 13, 2015 6:04 AM
> >> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
> >> questions)
> >> Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
> >> [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> >>
> >>
> >>
> >> On 11/13/15, 3:23 PM, "Flavio Percoco"  wrote:
> >>
> >>> On 10/11/15 16:11 +0100, Alan Pevec wrote:
>  Hi,
> 
>  while we continue discussion about the future of stable branches in
>  general and stable/juno in particular, I'd like to execute the
> >> current
>  plan which was[1]
> 
>  2014.2.4 (eol) early November, 2015. release manager: apevec
> 
>  Iff there's enough folks interested (I'm not) in keep Juno alive
> >>
> >> +1 I do not see any reason why we should still invest time and effort
> >> here. Lets focus on stable/kilo
> >>
>  longer, they could resurrect it but until concrete plan is done
>  let's be honest and stick to the agreed plan.
> 
>  This is a call to stable-maint teams for Nova, Keystone, Glance,
>  Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to
> >> review
>  open stable/juno changes[2] and approve/abandon them as
> appropriate.
>  Proposed timeline is:
>  * Thursday Nov 12 stable/juno freeze[3]
>  * Thursday Nov 19 release 2014.2.1
> 
> >>>
> >>> General ack from a stable-maint point of view! +1 on the above
> >>>
> >>> Flavio
> >>>
>  Cheers,
>  Alan
> 
>  [1]
>  https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.
>  2F
> >> juno
>  _releases_.2812_months.29
> 
>  [2]
> 
> https://review.openstack.org/#/q/status:open+AND+branch:stable/juno
>  +A
> >> ND+%
> 
> 28project:openstack/nova+OR+project:openstack/keystone+OR+project:o
>  pe
> >> nsta
> 
> ck/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+
>  OR
> >> +pro
> 
> ject:openstack/horizon+OR+project:openstack/heat+OR+project:opensta
>  ck
> >> /cei
> 
> lometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n
>  lometer+OR+,z
> 
>  [3] documented  in
> 
> https://wiki.openstack.org/wiki/StableBranch#Stable_release_manager
>  s
>  TODO add in new location
>  http://docs.openstack.org/project-team-guide/stable-branches.html
> 
> 
> __
> _
>  __
> >> 
>  _
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>> --
> >>> @flaper87
> >>> Flavio Percoco
> >>
> >>
> >>
> __
> ___
> >> __
> >> ___
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-
> >> requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> I'm assuming you mean grenade runs on stable/kilo. A grenade job on
> stable/kilo is installing stable/juno and then upgrading to stable/kilo (the
> change being tested is on stable/kilo). The grenade jobs for stable/juno were
> stopped when icehouse-eol happened.
> 
> Arguably we could still be testing grenade on stable/kilo by just installing
> Juno 2014.2.4 (last Juno