[tripleo] Changing TripleO's release model
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.
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
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 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 or 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.
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
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 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?.
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
Le mer. 9 juin 2021 à 10:05, Alfredo Moralejo Alonso amoralej@redhat.com a écrit :
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?
Feature freeze doesn't exist in the independent model. The independent model isn't bound with the openstack series. Usually the independent model is more suitable for stable projects, deliverables that are in use outside openstack or for deliverables that aren't related to openstack series (e.g openstack/pbr).
- 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 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.
How do you plan to manage the different versions of OSP without upstream
branches? Backports can be done by defining downstream branches for OSP, however, that will introduce a gymnastic to filter and select the changes to backport, the sealing between OSP versions will be more difficult to manage downstream. That leads us to the next question.
How to deal with RDO? If I'm right RDO is branch based ( https://www.rdoproject.org/what/repos/), that will force some updates here too. That will also impact tools like packstack ( https://www.rdoproject.org/install/packstack/).
What does this change mean in terms of branches and compatibility for OpenStack stable releases?.
The independent release model means no stable branches anymore for deliverables that follow this model (e.g openstack/pbr). The deliverables that stick to this model aren't no longer coordinated by the openstack series (A, B, C..., Ussuri, Victoria, Wallaby, Xena, Y, Z).
However, we should notice that the independent model is different from branchless. Branches can be created by project owners, however, these branches won't be released by the release team, only the master branch will be released. So, maybe you could emulate the OSP versions upstream (some sort of stable branches) and then backport patches to them, however, you'll have to release them by yourself.
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
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 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?
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
On Wed, Jun 9, 2021 at 11:06 AM Marios Andreou marios@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 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?
For me it's fine if TripleO provides a list of tags which are able to deploy and coinstall with a certain OpenStack release, let's say stable/Y, i don't see much problem on that, we'd need to figure out how to express that as code.
The actual problem I see is how to maintain that working overtime during the maintenance phase of release Y without stable/Y branches or CI jobs for old releases. Let's assume that at GA time for Y you provide a list of tags for tripleo projects coming from the master branch. How will you manage a bug affecting to tripleo on release Y or introduced by any changing factor (OS updates, etc...)?, will master branch be kept tested and compatible with both master and stable/Y (as branchless project do, i.e. tempest)?. Note that frequent releases on master branches will not help to support Y release if a change in the branch depends on changes done in more recent releases.
From RDO, we don't require all packages to have stable branches (we include
independent or branchless packages in the distro) but we want to provide a validated combination of packages working for a certain synchronized release and with the mechanism to fix it if it breaks during the maintenance period. I'm not sure how tripleo can do this without branches or maintaining backwards compatibility in master or other branches.
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
-- _sent from my mobile - sorry for spacing spelling etc_
On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou 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 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.
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
On Wed, Jun 9, 2021 at 1:49 PM Sean Mooney smooney@redhat.com wrote:
On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou 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
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-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
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
On Wed, 2021-06-09 at 15:17 +0200, Alfredo Moralejo Alonso wrote:
On Wed, Jun 9, 2021 at 1:49 PM Sean Mooney smooney@redhat.com wrote:
On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou 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
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-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
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. 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
On 6/9/21 3:57 PM, Sean Mooney wrote:
On Wed, 2021-06-09 at 15:17 +0200, Alfredo Moralejo Alonso wrote:
On Wed, Jun 9, 2021 at 1:49 PM Sean Mooney smooney@redhat.com wrote:
On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou 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
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-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
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. 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.
I'm sceptical about if that makes lives simpler. As we learned earlier in the topic, "stable" tags would still require maintenance branches to be managed manually (with only a 3rd side CI available for that?). And manual solving of drifting dependencies collisions (since no more appropriate requirements-checks automation for independently released tripleo?). Finally, openstack puppet modules and puppet-tripleo look too much specific to OpenStack configuration options, that may drift a lot from release to a release, to be independently released.
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
On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney smooney@redhat.com wrote:
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.
I wouldn't characterize it as "leaking". Instead, we are aiming to accurately reflect what we intend to support as a community (not as any company), based on who we have working on this project.
Unfortunately the reality is that no one (community or otherwise) should use TripleO from rocky/stein/ussuri/victoria other than for dev/test in my opinion. There's no upgrade path from any of those releases, and the community isn't working on one. However, that is not clearly represented by the project. While we don't intend to retrofit this policy to past branches, part of proposing this change is to help clear that up going forward.
at least while tripleo is still in the Openstack namespaces and not the x namespaces.
I don't think I understand. At least..."what"? How is the OpenStack namespace related to release models? How does the namespace (which is a construct of how git repositories are organized aiui), have a relation to what is included in an OpenStack release?
Skipping upstream release is really quite a radical departure form the project original goals.
I disagree with how you remember the history, and I think this is an overstatement.
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 don't follow the premise. How is it counterproductive to move our testing close to upstream? We'd always continue to test master. When it comes time for OpenStack to branch, such as to create stable/xena in all the service projects, TripleO may choose not to branch, and I think at that point, TripleO would no longer have CI jobs running on stable/xena of those service projects.
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.
I think the "when ready" is part of the problem here. For example, one might look at when we released stable/victoria and claim TripleO was ready. However, when TripleO victoria was released, you could not upgrade from ussuri to victoria. Likewise, you can't upgrade from victoria to wallaby. Were we really ready to release? My take is that we shouldn't have released at all. I think it sends a false signal.
An alternative to this entire proposal would be to double down on making TripleO more fully support each OpenStack stable branch. That would mean adding update/upgrade jobs for each stable branch, and doing the development work to actually implement that support (if it's not tested, it's broken), as well as likely adding other missing jobs instead of de-emphasizing testing on these branches.
AIUI, we do not want to be adding additional CI jobs of that scale upstream, especially given the complaints about node usage from TripleO from earlier in this cycle. And, we do not have the humans to develop and maintain this additional work.
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 think moving to the independent model does enable us to consider releasing sooner.
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.
We'd continue to always CI master.
Not all stable branches would remain covered by TripleO. For example, if TripleO didn't branch and release for xena, you wouldn't have TripleO jobs on nova stable/xena patches. Those jobs don't provide any meaningful feedback for TripleO. Perhaps they do for nova as you are backporting a change through every branch, and you're final destination is a branch where TripleO is expected to be working, such as wallaby. You would want to know if the change broke on xena for example, or if it were something on wallaby. I can see how that would be useful for nova.
However, part of what we're saying is that TripleO is trying to simplify what we are supporting and testing, so we can get better at supporting the releases that are most important to our community. Yes, there is some downstream influence here, in the same way that TripleO doesn't support deploying with Ubuntu, because it is less important to our (TripleO) community. I think that's ok, and I see nothing wrong with it.
If the service projects (such as nova) want to commit additional resources and the upstream CI node count can handle the increase that properly supporting each stable branch implies, then I think we can weigh that option as well. However, the current status quo of more or less just checking the boxes on each stable branch is wrong and sends a false message in my opinion. That's a big part of what we're trying to correct.
On Wed, Jun 9, 2021 at 8:06 AM James Slagle james.slagle@gmail.com wrote:
On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney smooney@redhat.com wrote:
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.
I wouldn't characterize it as "leaking". Instead, we are aiming to accurately reflect what we intend to support as a community (not as any company), based on who we have working on this project.
Unfortunately the reality is that no one (community or otherwise) should use TripleO from rocky/stein/ussuri/victoria other than for dev/test in my opinion. There's no upgrade path from any of those releases, and the community isn't working on one. However, that is not clearly represented by the project. While we don't intend to retrofit this policy to past branches, part of proposing this change is to help clear that up going forward.
at least while tripleo is still in the Openstack namespaces and not the x namespaces.
I don't think I understand. At least..."what"? How is the OpenStack namespace related to release models? How does the namespace (which is a construct of how git repositories are organized aiui), have a relation to what is included in an OpenStack release?
Skipping upstream release is really quite a radical departure form the project original goals.
I disagree with how you remember the history, and I think this is an overstatement.
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 don't follow the premise. How is it counterproductive to move our testing close to upstream? We'd always continue to test master. When it comes time for OpenStack to branch, such as to create stable/xena in all the service projects, TripleO may choose not to branch, and I think at that point, TripleO would no longer have CI jobs running on stable/xena of those service projects.
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.
I think the "when ready" is part of the problem here. For example, one might look at when we released stable/victoria and claim TripleO was ready. However, when TripleO victoria was released, you could not upgrade from ussuri to victoria. Likewise, you can't upgrade from victoria to wallaby. Were we really ready to release? My take is that we shouldn't have released at all. I think it sends a false signal.
An alternative to this entire proposal would be to double down on making TripleO more fully support each OpenStack stable branch. That would mean adding update/upgrade jobs for each stable branch, and doing the development work to actually implement that support (if it's not tested, it's broken), as well as likely adding other missing jobs instead of de-emphasizing testing on these branches.
AIUI, we do not want to be adding additional CI jobs of that scale upstream, especially given the complaints about node usage from TripleO from earlier in this cycle. And, we do not have the humans to develop and maintain this additional work.
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 think moving to the independent model does enable us to consider releasing sooner.
I think there's also something here that we should highlight in that it's desirable to be able to update the tripleo deployment process outside of openstack. By switching to independent and focusing on extracting the version specifics, we could allow for folks to leverage newer tripleo functionality (e.g. when we switched from mistral/zaqar to just ansible) without having to upgrade their openstack as well.
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.
We'd continue to always CI master.
Not all stable branches would remain covered by TripleO. For example, if TripleO didn't branch and release for xena, you wouldn't have TripleO jobs on nova stable/xena patches. Those jobs don't provide any meaningful feedback for TripleO. Perhaps they do for nova as you are backporting a change through every branch, and you're final destination is a branch where TripleO is expected to be working, such as wallaby. You would want to know if the change broke on xena for example, or if it were something on wallaby. I can see how that would be useful for nova.
However, part of what we're saying is that TripleO is trying to simplify what we are supporting and testing, so we can get better at supporting the releases that are most important to our community. Yes, there is some downstream influence here, in the same way that TripleO doesn't support deploying with Ubuntu, because it is less important to our (TripleO) community. I think that's ok, and I see nothing wrong with it.
If the service projects (such as nova) want to commit additional resources and the upstream CI node count can handle the increase that properly supporting each stable branch implies, then I think we can weigh that option as well. However, the current status quo of more or less just checking the boxes on each stable branch is wrong and sends a false message in my opinion. That's a big part of what we're trying to correct.
--
-- James Slagle
On Wed, 2021-06-09 at 09:58 -0400, James Slagle wrote:
On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney smooney@redhat.com wrote:
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.
I wouldn't characterize it as "leaking". Instead, we are aiming to accurately reflect what we intend to support as a community (not as any company), based on who we have working on this project.
Unfortunately the reality is that no one (community or otherwise) should use TripleO from rocky/stein/ussuri/victoria other than for dev/test in my opinion. There's no upgrade path from any of those releases, and the community isn't working on one. However, that is not clearly represented by the project. While we don't intend to retrofit this policy to past branches, part of proposing this change is to help clear that up going forward.
if that is the general consensus yes i think it would be good to update the docs to highlight that. i had assumed that the goal of ooo was to have all upstream releases be production ready independent of if that is productized downstream.
at least while tripleo is still in the Openstack namespaces and not the x namespaces.
I don't think I understand. At least..."what"? How is the OpenStack namespace related to release models? How does the namespace (which is a construct of how git repositories are organized aiui), have a relation to what is included in an OpenStack release?
i was more thinking that perhaps if ooo was moving away form the corodianted releases it might make more sense for it to move to a spereate top level project like starlinx so rather then x/ namespace maybe a top level tripleo namesapace to better refalect that while it deploy openstack it does not follow the ame release cadance. coupled with the fact that ooo already those not follow the normal stable backport policies that other openstack proejct follow and the recent dicussing about opting out of the global requirement process it just felt like ooo was moving away form being a part of openstack to being a related porjects like starlingx.
Skipping upstream release is really quite a radical departure form the project original goals.
I disagree with how you remember the history, and I think this is an overstatement.
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 don't follow the premise. How is it counterproductive to move our testing close to upstream? We'd always continue to test master. When it comes time for OpenStack to branch, such as to create stable/xena in all the service projects, TripleO may choose not to branch, and I think at that point, TripleO would no longer have CI jobs running on stable/xena of those service projects.
so for other project i guess the impact of that would be removing the triplo job form our our ci piplines for the stable branch.
for nova we do not currently hav eany ooo based ci jobs but we had breifly discussed having ooo-standalone job to do some centos/ooo based testing at one point. destack is generally the correct tool to test change to nova but if ooo was to skip stable release i think it would mean it would not be a candiate for other project to use in there ci as an alternivie. that is a valid choice for the ooo to make but it effectlivy means we will never have a ooo voting jobs in nova if ooo does start skiping upstream releases.
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.
I think the "when ready" is part of the problem here. For example, one might look at when we released stable/victoria and claim TripleO was ready. However, when TripleO victoria was released, you could not upgrade from ussuri to victoria. Likewise, you can't upgrade from victoria to wallaby. Were we really ready to release? My take is that we shouldn't have released at all. I think it sends a false signal.
well honestly if i was using ooo as my deployment tool i would have expected upgrade support to be completed prior to the reslease yes but i think this is not an artifact of the release cycle but rather an artifact that upgrade support is not part of the DOD of enabling a new feature in ooo. e.g. if master was required to be alwasy upgradable for previous release we would not have this issue. that is a lot more work though.
An alternative to this entire proposal would be to double down on making TripleO more fully support each OpenStack stable branch. That would mean adding update/upgrade jobs for each stable branch, and doing the development work to actually implement that support (if it's not tested, it's broken), as well as likely adding other missing jobs instead of de-emphasizing testing on these branches.
yes. personally i would prefer if we went in this direction, again i know why from a downstream persepctive we may not want to do this but in my personal capasity if i was evaluating a deployment tool n to n+1 update in place of upstream release would be part of my minimum viable product.
AIUI, we do not want to be adding additional CI jobs of that scale upstream, especially given the complaints about node usage from TripleO from earlier in this cycle. And, we do not have the humans to develop and maintain this additional work.
ack i know we are both human an machine constrained to go this path. actully supporting multinode standalone and upgrades of standalone deployments would have signinficnatly reduced the ci time and resouces required but we also dont have the resouces to eanable that :(
we have been trying on and off to enable that for https://opendev.org/openstack/whitebox-tempest-plugin so that we can better test changes before they hit downstream ci but i think that idea has more or less stalled out.
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 think moving to the independent model does enable us to consider releasing sooner.
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.
We'd continue to always CI master.
Not all stable branches would remain covered by TripleO. For example, if TripleO didn't branch and release for xena, you wouldn't have TripleO jobs on nova stable/xena patches. Those jobs don't provide any meaningful feedback for TripleO. Perhaps they do for nova as you are backporting a change through every branch, and you're final destination is a branch where TripleO is expected to be working, such as wallaby. You would want to know if the change broke on xena for example, or if it were something on wallaby. I can see how that would be useful for nova.
yes today we use devstack to validate that which honestly is enough 99% of the time where it can be chalanging is if the issue we are fixing is centos/ooo specific granted we dont currently have ooo based ci on the project i work on so its not really a decrese in capability.
we had discussed possible using upstream ooo to start early validation of new feature after the completion of an upstream cycle form a branch that would not be the bases of an downstream relesase. we might be able to get the same effect just using master but the idea was to test earlier.
However, part of what we're saying is that TripleO is trying to simplify what we are supporting and testing, so we can get better at supporting the releases that are most important to our community. Yes, there is some downstream influence here, in the same way that TripleO doesn't support deploying with Ubuntu, because it is less important to our (TripleO) community. I think that's ok, and I see nothing wrong with it.
ack, that is fair and im not really concerned by that. i think its correct to serve the need of the comunity that consume the project.
If the service projects (such as nova) want to commit additional resources and the upstream CI node count can handle the increase that properly supporting each stable branch implies, then I think we can weigh that option as well. However, the current status quo of more or less just checking the boxes on each stable branch is wrong and sends a false message in my opinion. That's a big part of what we're trying to correct.
ack. honestly without multinode standalone and upgrade support for the same i dont actully think it would add much value above just having a devstack centos job when we are concerned about cenost/rhel specific things.
the reason i reponed initally was mainly propted by the implication that a ooo change in direction woudl nessatatye rdo to also change its release cycle but that is not what was being proposed or what will happen so you can consider my question/comments more or less adressed.
On 6/9/21 3:58 PM, James Slagle wrote:
On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney <smooney@redhat.com mailto:smooney@redhat.com> wrote:
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.I wouldn't characterize it as "leaking". Instead, we are aiming to accurately reflect what we intend to support as a community (not as any company), based on who we have working on this project.
Unfortunately the reality is that no one (community or otherwise) should use TripleO from rocky/stein/ussuri/victoria other than for dev/test in my opinion. There's no upgrade path from any of those releases, and the community isn't working on one. However, that is not clearly represented by the project. While we don't intend to retrofit this policy to past branches, part of proposing this change is to help clear that up going forward.
at least while tripleo is still in the Openstack namespaces and not the x namespaces.I don't think I understand. At least..."what"? How is the OpenStack namespace related to release models? How does the namespace (which is a construct of how git repositories are organized aiui), have a relation to what is included in an OpenStack release?
Skipping upstream release is really quite a radical departure form the project original goals.I disagree with how you remember the history, and I think this is an overstatement.
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 don't follow the premise. How is it counterproductive to move our testing close to upstream? We'd always continue to test master. When it comes time for OpenStack to branch, such as to create stable/xena in all the service projects, TripleO may choose not to branch, and I think at that point, TripleO would no longer have CI jobs running on stable/xena of those service projects.
Since TripleO does not follow the stable branch policy, isn't the same possible as well today without switching to the independent release model?
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.I think the "when ready" is part of the problem here. For example, one might look at when we released stable/victoria and claim TripleO was ready. However, when TripleO victoria was released, you could not upgrade from ussuri to victoria. Likewise, you can't upgrade from victoria to wallaby. Were we really ready to release? My take is that we shouldn't have released at all. I think it sends a false signal.
An alternative to this entire proposal would be to double down on making TripleO more fully support each OpenStack stable branch. That would mean adding update/upgrade jobs for each stable branch, and doing the development work to actually implement that support (if it's not tested, it's broken), as well as likely adding other missing jobs instead of de-emphasizing testing on these branches.
AIUI, we do not want to be adding additional CI jobs of that scale upstream, especially given the complaints about node usage from TripleO from earlier in this cycle. And, we do not have the humans to develop and maintain this additional work.
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 think moving to the independent model does enable us to consider releasing sooner.
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.We'd continue to always CI master.
Not all stable branches would remain covered by TripleO. For example, if TripleO didn't branch and release for xena, you wouldn't have TripleO jobs on nova stable/xena patches. Those jobs don't provide any meaningful feedback for TripleO. Perhaps they do for nova as you are backporting a change through every branch, and you're final destination is a branch where TripleO is expected to be working, such as wallaby. You would want to know if the change broke on xena for example, or if it were something on wallaby. I can see how that would be useful for nova.
However, part of what we're saying is that TripleO is trying to simplify what we are supporting and testing, so we can get better at supporting the releases that are most important to our community. Yes, there is some downstream influence here, in the same way that TripleO doesn't support deploying with Ubuntu, because it is less important to our (TripleO) community. I think that's ok, and I see nothing wrong with it.
If the service projects (such as nova) want to commit additional resources and the upstream CI node count can handle the increase that properly supporting each stable branch implies, then I think we can weigh that option as well. However, the current status quo of more or less just checking the boxes on each stable branch is wrong and sends a false message in my opinion. That's a big part of what we're trying to correct.
--
-- James Slagle
On Wednesday, June 9, 2021, 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?
if you mean tripleo contributors then in the usual manner i.e. this mailing list, the IRC meeting etc
if you mean the other openstack projects then that hasnt really ever applied since tripleo always has trailed the openstack release.
the main thing this buys us is the ability to skip creating a particular branch (assuming we go ahead... for example not creating stable/Y when that time comes) or creating it *much* later than the trailing release model allows us which is 6 months if i recall correctly. In which case again feature freeze wouldnt apply since that stable branch would already have been created by the openstack projects
regards , marios
- 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 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.
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
On Tue, Jun 8, 2021 at 6:21 PM Wesley Hayutin whayutin@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 or 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.
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
Hello TripleO and friends o/,
It has been over a month since we first introduced this proposal in tripleo meetings and weshay started this thread. Now that we have allowed enough time for comments and debate, we’d like to re-focus on making a decision.
The timing with this change to our release governance is critical to stable/xena. One of the main concerns is that CentOS-Stream-9 may not be fully available by the xena release. TripleO would have to carry both CentOS-Stream-8 and CentOS-Stream-9 across wallaby and xena and master, thus exploding our upstream resource consumption. The counterpoint to that is that we are only a few months away from xena releasing.
As a summary and reminder the three main concerns raised in this thread so far were
1. What about compatibility with (rest of) openstack stable branches 2. How are feature freeze dates affected (& coordination with other projects around feature freeze) 3. How does it affect RDO packaging?
For 2 and 3 as discussed there will be no implications; RDO has no plans to stop packaging for any particular branch so non tripleo packages will be built as usual, and, feature freeze (with respect to the rest of openstack) doesn’t apply for tripleo since it has always been trailing release.
For 1 the current proposal is that we will use git tags; a range of tags will be designated as compatible with a given stable/release. Obviously this needs some more thought and establishing some rules (like, bumping major to signal compatibility with a new stable branch). To that end we will start a spec (tripleo-specs) to work out this and other details and allow folks to comment further.
This topic will also be raised in the IRC meeting this coming Tuesday 20 July [1] so please join us if you are interested in discussing any of the points raised here or any new ones that we missed last time,
regards, marios
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html
On Mon, Jul 19, 2021 at 5:50 PM Marios Andreou marios@redhat.com wrote:
On Tue, Jun 8, 2021 at 6:21 PM Wesley Hayutin whayutin@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 or 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.
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
Hello TripleO and friends o/,
It has been over a month since we first introduced this proposal in tripleo meetings and weshay started this thread. Now that we have allowed enough time for comments and debate, we’d like to re-focus on making a decision.
The timing with this change to our release governance is critical to stable/xena. One of the main concerns is that CentOS-Stream-9 may not be fully available by the xena release. TripleO would have to carry both CentOS-Stream-8 and CentOS-Stream-9 across wallaby and xena and master, thus exploding our upstream resource consumption. The counterpoint to that is that we are only a few months away from xena releasing.
As a summary and reminder the three main concerns raised in this thread so far were
- What about compatibility with (rest of) openstack stable branches
- How are feature freeze dates affected (& coordination with other
projects around feature freeze) 3. How does it affect RDO packaging?
For 2 and 3 as discussed there will be no implications; RDO has no plans to stop packaging for any particular branch so non tripleo packages will be built as usual, and, feature freeze (with respect to the rest of openstack) doesn’t apply for tripleo since it has always been trailing release.
For 1 the current proposal is that we will use git tags; a range of tags will be designated as compatible with a given stable/release. Obviously this needs some more thought and establishing some rules (like, bumping major to signal compatibility with a new stable branch). To that end we will start a spec (tripleo-specs) to work out this and other details and allow folks to comment further.
spec is posted there https://review.opendev.org/c/openstack/tripleo-specs/+/801512 please add your comments
regards, marios
This topic will also be raised in the IRC meeting this coming Tuesday 20 July [1] so please join us if you are interested in discussing any of the points raised here or any new ones that we missed last time,
regards, marios
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html
On Fri, Jul 23, 2021 at 8:52 AM Marios Andreou marios@redhat.com wrote:
On Mon, Jul 19, 2021 at 5:50 PM Marios Andreou marios@redhat.com wrote:
On Tue, Jun 8, 2021 at 6:21 PM Wesley Hayutin whayutin@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 or 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.
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
Hello TripleO and friends o/,
It has been over a month since we first introduced this proposal in tripleo meetings and weshay started this thread. Now that we have allowed enough time for comments and debate, we’d like to re-focus on making a decision.
The timing with this change to our release governance is critical to stable/xena. One of the main concerns is that CentOS-Stream-9 may not be fully available by the xena release. TripleO would have to carry both CentOS-Stream-8 and CentOS-Stream-9 across wallaby and xena and master, thus exploding our upstream resource consumption. The counterpoint to that is that we are only a few months away from xena releasing.
As a summary and reminder the three main concerns raised in this thread so far were
- What about compatibility with (rest of) openstack stable branches
- How are feature freeze dates affected (& coordination with other
projects around feature freeze) 3. How does it affect RDO packaging?
For 2 and 3 as discussed there will be no implications; RDO has no plans to stop packaging for any particular branch so non tripleo packages will be built as usual, and, feature freeze (with respect to the rest of openstack) doesn’t apply for tripleo since it has always been trailing release.
For 1 the current proposal is that we will use git tags; a range of tags will be designated as compatible with a given stable/release. Obviously this needs some more thought and establishing some rules (like, bumping major to signal compatibility with a new stable branch). To that end we will start a spec (tripleo-specs) to work out this and other details and allow folks to comment further.
spec is posted there https://review.opendev.org/c/openstack/tripleo-specs/+/801512 please add your comments
regards, marios
This topic will also be raised in the IRC meeting this coming Tuesday 20 July [1] so please join us if you are interested in discussing any of the points raised here or any new ones that we missed last time,
regards, marios
[1]
http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html
FYI.. TripleO is now under OpenStack's independent release model governance.
Thanks for everyone's time and input :)
participants (9)
-
Alex Schultz
-
Alfredo Moralejo Alonso
-
Bogdan Dobrelya
-
Dan Sneddon
-
Herve Beraud
-
James Slagle
-
Marios Andreou
-
Sean Mooney
-
Wesley Hayutin