Open Stack

On Wed, Jun 9, 2021 at 1:49 PM Sean Mooney <smooney at redhat.com> wrote:

> On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou wrote:
> > On Wednesday, June 9, 2021, Alfredo Moralejo Alonso <amoralej at redhat.com
> >
> > wrote:
> >
> > >
> > >
> > > On Wed, Jun 9, 2021 at 2:48 AM Dan Sneddon <dsneddon at redhat.com>
> wrote:
> > >
> > > > Thanks for making the announcement. Can you clarify how the
> > > > feature-freeze dates will be communicated to the greater community of
> > > > contributors?
> > > >
> > > > - Dan Sneddon
> > > >
> > > > On Jun 8, 2021, at 8:21 AM, Wesley Hayutin <whayutin at redhat.com>
> wrote:
> > > >
> > > > 
> > > >
> > > > Greetings TripleO community!
> > > >
> > > > At the most recent TripleO community meetings we have discussed
> formally
> > > > changing the OpenStack release model for TripleO [1].  The previous
> > > > released projects can be found here [2]. TripleO has previously
> released
> > > > with release-type[‘trailing’, ‘cycle-with-intermediary’].
> > > >
> > > > To quote the release model doc:
> > > >
> > > > ‘Trailing deliverables trail the release, so they cannot, by
> definition,
> > > > be independent. They need to pick between cycle-with-rc
> > > > <
> https://releases.openstack.org/reference/release_models.html#cycle-with-rc
> >
> > > > or cycle-with-intermediary
> > > > <
> https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary
> >
> > > > models.’
> > > >
> > > > We are proposing to update the release-model to ‘independent’.  This
> > > > would give the TripleO community more flexibility in when we choose
> to cut
> > > > a release.  In turn this would mean less backporting, less upstream
> and 3rd
> > > > party resources used by potentially some future releases.
> > > >
> > > >
> > > What does this change mean in terms of branches and compatibility for
> > > OpenStack stable releases?.
> > >
> > >
> >
> >
> > as i wrote to Dan just now the main thing is that we may delay or even
> skip
> > a particular branch. For compatibility I guess it means we would have to
> > rely on git tags so perhaps making consistently frequent (eg monthly? or
> > more?) releases for all the tripleo repos. You could then call a
> particular
> > range of tags as being compatible with stable/Y for example. Does it
> sound
> > sane/doable from an rdo package build perspective?
> >
> too me this feels like we are leaking downstream product lifecycle into
> upstream.
> even if redhat is overwhelmingly the majority contibutor of reviews and
> commits to
> ooo im not sure that changing the upstream lifestyle to align more closely
> with our product life
> cycle is the correct thing to do.
>
> at least while tripleo is still in the Openstack namespaces and not the x
> namespaces.
> Skipping upstream release is really quite a radical departure form the
> project original goals.
> i think it would also be counter productive to our downstream efforts to
> move our testing close to upstream.
> if ooo was to lose the ablity to test master for example we would not be
> able to use ooo in our downstream ci to test
> feature that we plan to release osp n+1 that are develop during an
> upstream cycle that wont be productised.
>
> i do not work on ooo so at the end of the day this wont affect me much but
> to me skipping releases seam counter intuitive
> given the previous efforts to make ooo more usable for development and ci.
> Moving to independent
> to decouple the lifecycle seams more reasonable if the underlying goal is
> not to skip releases. you can release when ready
> rather then scrambling or wating for a deadline. personally i think moving
> in the other direction so that ooo can release sooner
> not later would make the project more appealing as the delay in support of
> a release is often considered a detractor for tripleo vs
> other openstack installers.
>
> i would hope that this change would not have any effect on the rdo
> packaging of non ooo packages.
> the rdo packages are used by other instalation methods (the puppet moduels
> for example) including i belive some of the larger chineese providers that
> have written there own installers. i think it would be damaging to centos
> if rdo was to skip upstream version of say nova. what might need to change
> is the packaging of ooo itself in rdo.
>
> tl;dr im not against the idea of ooo moving to independent model but i
> would hope that it will not affect RDO's packaging of non ooo projects and
> that
> ooo can still be used for ci of master and stable branches of for example
> nova.
>
>

RDO has no plans on skipping releases or any other changes affecting
non-tripleo packages. The impact of this change (unclear at this point)
should only affect the packages for those repos.

Note that RDO aims at being used and useful for other users and deployment
tools as Puppet modules, Kolla, or others willing to work in CentOS and
we'd like to maintain the collaboration with them as needed.

Regards,

Alfredo


> regards
> sean
>
> >
> > regards, marios
> >
> >
> >
> >
> > > To quote the release model doc:
> > > >
> > > > ‘Some projects opt to completely bypass the 6-month cycle and release
> > > > independently. For example, that is the case of projects that
> support the
> > > > development infrastructure. The “independent” model describes such
> > > > projects.’
> > > >
> > > > The discussion here is to merely inform the greater community with
> > > > regards to the proposal and conversations regarding the release
> model.
> > > > This thread is NOT meant to discuss previous releases or their
> supported
> > > > status, merely changing the release model here [3]
> > > >
> > > >
> > > > [0] https://etherpad.opendev.org/p/tripleo-meeting-items
> > > >
> > > > [1]  https://releases.openstack.org/reference/release_models.html
> > > >
> > > > [2] https://releases.openstack.org/teams/tripleo.html
> > > >
> > > > [3] https://opendev.org/openstack/releases/src/branch/master/
> > > > deliverables/xena
> > > >
> > > >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210609/10d57ad4/attachment.html>