On Wed, Jun 9, 2021 at 1:49 PM Sean Mooney <smooney@redhat.com> wrote:
On Wednesday, June 9, 2021, Alfredo Moralejo Alonso <amoralej@redhat.com
wrote:
On Wed, Jun 9, 2021 at 2:48 AM Dan Sneddon <dsneddon@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@redhat.com>
wrote:
Greetings TripleO community!
At the most recent TripleO community meetings we have discussed
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-inte...
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
On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou wrote: formally 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. ack
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. ya that is what i was expecting. thanks for confirming.
On Wed, 2021-06-09 at 15:17 +0200, Alfredo Moralejo Alonso wrote: provided the possible change in ooo direction does not negatively impact the other consumes of rdo i dont really have an objection to ooo changing how they work if peolel think it will make there lives and there customer live simpler in the long run. as i said i do not work on or use ooo frequently but i have consumed the output of rdo via kolla in the past and while i typeically prefer using the source install i know many do use the centos binary install variant using the rdo packages.
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