Open Stack

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: Tuesday, November 17, 2015 2:57 AM
> To: openstack-dev at 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:gkotton at 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" <flavio at redhat.com> 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-request at 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-
> >> request at 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-request at 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 point release before EOL) and then upgrading to
> stable/kilo.
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 

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?

- Erno