Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
On 9/20/2017 9:42 AM, arkady.kanev...@dell.com wrote: Lee, I can chair meeting in Sydney. Thanks, Arkady Arkady, Are you actually moderating the forum session in Sydney because the session says Eric McCormick is the session moderator: https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20451/fast-forward-upgrades People are asking in the nova IRC channel about this session and were told to ask Jay Pipes about it, but Jay isn't going to be in Sydney and isn't involved in fast-forward upgrades, as far as I know anyway. So whoever is moderating this session, can you please create an etherpad and get it linked to the wiki? https://wiki.openstack.org/wiki/Forum/Sydney2017 -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
On 21-09-17 15:10:52, Thierry Carrez wrote: > Sean Dague wrote: > > Agreed. We're already at 5 upgrade tags now? > > > > I think honestly we're going to need a picture to explain the > > differences between them. Based on the confusion that kept seeming to > > come during discussions at the PTG, I think we need to circle around and > > figure out if there are different ways to explain this to have greater > > clarity. > > In the TC/SWG room we reviewed the tags, and someone suggested that any > tag that doesn't even have one project to apply it to should probably be > removed. > > That would get us rid of 3 of them: supports-accessible-upgrade, > supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+ > supports-api-interoperability which has had little support so far). > > They can always be resurrected when a project reaches new heights? I've added some brief comments to the following change looking to remove the `supports-accessible-upgrade` tag: Remove assert:supports-accessible-upgrade tag https://review.openstack.org/#/c/506263/ Grenade already verifies that some resources are accessible once services are offline at the start of an upgrade[1][2] for a number of projects such as nova[3] and cinder[4]. I think that's enough to keep the tag around and to also associate any such project with this tag. [1] https://github.com/openstack-dev/grenade#basic-flow [2] https://github.com/openstack-dev/grenade/blob/03de9e0fc7f4fc50a00db5d547413e26cf0780dd/grenade.sh#L315-L317 [3] https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/resources.sh#L134-L137 [4] https://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resources.sh#L230-L243 Lee -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
On 20-09-17 14:56:20, arkady.kanev...@dell.com wrote: > Lee, > I can chair meeting in Sydney. > Thanks, > Arkady Thanks Arkady! FYI I see that emccormickva has created the following Forum session to discuss FF upgrades: http://forumtopics.openstack.org/cfp/details/19 You might want to reach out to him to help craft the agenda for the session based on our discussions in Denver. Thanks again, Lee -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
On 2017-09-21 13:29:53 -0400 (-0400), Doug Hellmann wrote: [...] > On the other hand, some of those were meant to be aspirational, so > not documenting them may mean no one is thinking about them at > all. Previous tags were added to document existing state/practices and came with projects already meeting their criteria. We've got other mechanisms for identifying features to which software can aspire... adding "vaporware" tags in an attempt to feel out what a taxonomy of upgrade models *might* look like seems more likely to confuse consumers of that data than provide useful information. -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Excerpts from Thierry Carrez's message of 2017-09-21 17:10:52 +0200: > Sean Dague wrote: > > Agreed. We're already at 5 upgrade tags now? > > > > I think honestly we're going to need a picture to explain the > > differences between them. Based on the confusion that kept seeming to > > come during discussions at the PTG, I think we need to circle around and > > figure out if there are different ways to explain this to have greater > > clarity. > > In the TC/SWG room we reviewed the tags, and someone suggested that any > tag that doesn't even have one project to apply it to should probably be > removed. > > That would get us rid of 3 of them: supports-accessible-upgrade, > supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+ > supports-api-interoperability which has had little support so far). > > They can always be resurrected when a project reaches new heights? > On the other hand, some of those were meant to be aspirational, so not documenting them may mean no one is thinking about them at all. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Sean Dague wrote: > Agreed. We're already at 5 upgrade tags now? > > I think honestly we're going to need a picture to explain the > differences between them. Based on the confusion that kept seeming to > come during discussions at the PTG, I think we need to circle around and > figure out if there are different ways to explain this to have greater > clarity. In the TC/SWG room we reviewed the tags, and someone suggested that any tag that doesn't even have one project to apply it to should probably be removed. That would get us rid of 3 of them: supports-accessible-upgrade, supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+ supports-api-interoperability which has had little support so far). They can always be resurrected when a project reaches new heights? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
On 09/20/2017 02:25 PM, Doug Hellmann wrote: Excerpts from Dan Smith's message of 2017-09-20 10:09:54 -0700: - Modify the `supports-upgrades`[3] and `supports-accessible-upgrades`[4] tags I have yet to look into the formal process around making changes to these tags but I will aim to make a start ASAP. We've previously tried to avoid changing assert tag definitions because we then have to re-review all of the projects that already have the tags to ensure they meet the new criteria. It might be easier to add a new tag for assert:supports-fast-forward-upgrades with the criteria that are unique to this use case. We already have a confusing array of upgrade tags, so I would really rather not add more that overlap in complicated ways. Most of the change here is clarification of things I think most people assume, so I don't think the validation effort will be a lot of work. --Dan OK, I'll wait to see what the actual updates look like before commenting further, but it sounds like working on the existing tag definitions is a good first step. Agreed. We're already at 5 upgrade tags now? I think honestly we're going to need a picture to explain the differences between them. Based on the confusion that kept seeming to come during discussions at the PTG, I think we need to circle around and figure out if there are different ways to explain this to have greater clarity. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Excerpts from Dan Smith's message of 2017-09-20 10:09:54 -0700: > >> - Modify the `supports-upgrades`[3] and `supports-accessible-upgrades`[4] > >> tags > >> > >>I have yet to look into the formal process around making changes to > >>these tags but I will aim to make a start ASAP. > > > > We've previously tried to avoid changing assert tag definitions because > > we then have to re-review all of the projects that already have the tags > > to ensure they meet the new criteria. It might be easier to add a new > > tag for assert:supports-fast-forward-upgrades with the criteria that are > > unique to this use case. > > We already have a confusing array of upgrade tags, so I would really > rather not add more that overlap in complicated ways. Most of the change > here is clarification of things I think most people assume, so I don't > think the validation effort will be a lot of work. > > --Dan OK, I'll wait to see what the actual updates look like before commenting further, but it sounds like working on the existing tag definitions is a good first step. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
- Modify the `supports-upgrades`[3] and `supports-accessible-upgrades`[4] tags I have yet to look into the formal process around making changes to these tags but I will aim to make a start ASAP. We've previously tried to avoid changing assert tag definitions because we then have to re-review all of the projects that already have the tags to ensure they meet the new criteria. It might be easier to add a new tag for assert:supports-fast-forward-upgrades with the criteria that are unique to this use case. We already have a confusing array of upgrade tags, so I would really rather not add more that overlap in complicated ways. Most of the change here is clarification of things I think most people assume, so I don't think the validation effort will be a lot of work. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Excerpts from Lee Yarwood's message of 2017-09-20 14:29:12 +0100: > My thanks again to everyone who attended and contributed to the > skip-level upgrades track over the first two days of last weeks PTG. > I've included a short summary of our discussions below with a list of > agreed actions for Queens at the end. > > tl;dr s/skip-level/fast-forward/g > > https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades > > Monday - Define and rename > -- > > During our first session [1] we briefly discussed the history of the > skip-level upgrades effort within the community and the various > misunderstandings that have arisen from previous conversations around > this topic at past events. > > We agreed that at present the only way to perform upgrades between N and > N+>=2 releases of OpenStack was to upgrade linearly through each major > release, without skipping between the starting and target release of the > upgrade. > > This is contrary to previous discussions on the topic where it had been > suggested that releases could be skipped if DB migrations for these > releases were applied in bulk later in the process. As projects within > the community currently offer no such support for this it was agreed to > continue to use the supported N to N+1 upgrade jumps, albeit in a > minimal, offline way. > > The name skip-level upgrades has had an obvious role to play in the > confusion here and as such the renaming of this effort was discussed at > length. Various suggestions are listed on the pad but for the time being > I'm going to stick with the basic `fast-forward upgrades` name (FFOU, > OFF, BOFF, FFUD etc were all close behind). This removes any notion of > releases being skipped and should hopefully avoid any further confusion > in the future. > > Support by the projects for offline upgrades was then discussed with a > recent Ironic issue [2] highlighted as an example where projects have > required services to run before the upgrade could be considered > complete. The additional requirement of ensuring both workloads and the > data plane remain active during the upgrade was also then discussed. It > was agreed that both the `supports-upgrades` [3] and > `supports-accessible-upgrades` [4] tags should be updated to reflect > these requirements for fast-forward upgrades. > > Given the above it was agreed that this new definition of what > fast-forward upgrades are and the best practices associated with them > should be clearly documented somewhere. Various operators in the room > highlighted that they would like to see a high level document outline > the steps required to achieve this, hopefully written by someone with > past experience of running this type of upgrade. > > I failed to capture the names of the individuals who were interested in > helping out here. If anyone is interested in helping out here please > feel free to add your name to the actions either at the end of this mail > or at the bottom of the pad. > > In the afternoon we reviewed the current efforts within the community to > implement fast-forward upgrades, covering TripleO, Charms (Juju) and > openstack-ansible. While this was insightful to many in the room there > didn't appear to be any obvious areas of collaboration outside of > sharing best practice and defining the high level flow of a fast-forward > upgrade. > > Tuesday - NFV, SIG and actions > -- > > Tuesday started with a discussion around NFV considerations with > fast-forward upgrades. These ranged from the previously mentioned need > for the data plane to remain active during the upgrade to the restricted > nature of upgrades in NFV environments in terms of time and number of > reboots. > > It was highlighted that there are some serious as yet unresolved bugs in > Nova regarding the live migration of instances using SR-IOV devices. > This currently makes the moving of workloads either prior to or during > the upgrade particularly difficult. > > Rollbacks were also discussed and the need for any best practice > documentation around fast-forward upgrades to include steps to allow the > recovery of environments if things fail was also highlighted. > > We then revisited an idea from the first day of finding or creating a > SIG for this effort to call home. It was highlighted that there was a > suggestion in the packaging room to create a Deployment / Lifecycle SIG. > After speaking with a few individuals later in the week I've taken the > action to reach out on the openstack-sigs mailing list for further > input. > > Finally, during a brief discussion on ways we could collaborate and share > tooling for fast-forward upgrades a new tool to migrate configuration > files between N to N+>=2 releases was introduced [5]. While interesting > it was seen as a more generic utility that could also be used between N > to N+1 upgrades. AFAIK the authors joined the Oslo room shortly after > this session ended to gain more
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Lee, I can chair meeting in Sydney. Thanks, Arkady -Original Message- From: Lee Yarwood [mailto:lyarw...@redhat.com] Sent: Wednesday, September 20, 2017 8:29 AM To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org Subject: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary My thanks again to everyone who attended and contributed to the skip-level upgrades track over the first two days of last weeks PTG. I've included a short summary of our discussions below with a list of agreed actions for Queens at the end. tl;dr s/skip-level/fast-forward/g https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades Monday - Define and rename -- During our first session [1] we briefly discussed the history of the skip-level upgrades effort within the community and the various misunderstandings that have arisen from previous conversations around this topic at past events. We agreed that at present the only way to perform upgrades between N and N+>=2 releases of OpenStack was to upgrade linearly through each major release, without skipping between the starting and target release of the upgrade. This is contrary to previous discussions on the topic where it had been suggested that releases could be skipped if DB migrations for these releases were applied in bulk later in the process. As projects within the community currently offer no such support for this it was agreed to continue to use the supported N to N+1 upgrade jumps, albeit in a minimal, offline way. The name skip-level upgrades has had an obvious role to play in the confusion here and as such the renaming of this effort was discussed at length. Various suggestions are listed on the pad but for the time being I'm going to stick with the basic `fast-forward upgrades` name (FFOU, OFF, BOFF, FFUD etc were all close behind). This removes any notion of releases being skipped and should hopefully avoid any further confusion in the future. Support by the projects for offline upgrades was then discussed with a recent Ironic issue [2] highlighted as an example where projects have required services to run before the upgrade could be considered complete. The additional requirement of ensuring both workloads and the data plane remain active during the upgrade was also then discussed. It was agreed that both the `supports-upgrades` [3] and `supports-accessible-upgrades` [4] tags should be updated to reflect these requirements for fast-forward upgrades. Given the above it was agreed that this new definition of what fast-forward upgrades are and the best practices associated with them should be clearly documented somewhere. Various operators in the room highlighted that they would like to see a high level document outline the steps required to achieve this, hopefully written by someone with past experience of running this type of upgrade. I failed to capture the names of the individuals who were interested in helping out here. If anyone is interested in helping out here please feel free to add your name to the actions either at the end of this mail or at the bottom of the pad. In the afternoon we reviewed the current efforts within the community to implement fast-forward upgrades, covering TripleO, Charms (Juju) and openstack-ansible. While this was insightful to many in the room there didn't appear to be any obvious areas of collaboration outside of sharing best practice and defining the high level flow of a fast-forward upgrade. Tuesday - NFV, SIG and actions -- Tuesday started with a discussion around NFV considerations with fast-forward upgrades. These ranged from the previously mentioned need for the data plane to remain active during the upgrade to the restricted nature of upgrades in NFV environments in terms of time and number of reboots. It was highlighted that there are some serious as yet unresolved bugs in Nova regarding the live migration of instances using SR-IOV devices. This currently makes the moving of workloads either prior to or during the upgrade particularly difficult. Rollbacks were also discussed and the need for any best practice documentation around fast-forward upgrades to include steps to allow the recovery of environments if things fail was also highlighted. We then revisited an idea from the first day of finding or creating a SIG for this effort to call home. It was highlighted that there was a suggestion in the packaging room to create a Deployment / Lifecycle SIG. After speaking with a few individuals later in the week I've taken the action to reach out on the openstack-sigs mailing list for further input. Finally, during a brief discussion on ways we could collaborate and share tooling for fast-forward upgrades a new tool to migrate configuration files between N to N+>=2 releases was introduced [5]. While interesting it was seen as a more generic utility that coul
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Lee, I can chair meeting in Sydney. Thanks, Arkady -Original Message- From: Lee Yarwood [mailto:lyarw...@redhat.com] Sent: Wednesday, September 20, 2017 8:29 AM To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org Subject: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary My thanks again to everyone who attended and contributed to the skip-level upgrades track over the first two days of last weeks PTG. I've included a short summary of our discussions below with a list of agreed actions for Queens at the end. tl;dr s/skip-level/fast-forward/g https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades Monday - Define and rename -- During our first session [1] we briefly discussed the history of the skip-level upgrades effort within the community and the various misunderstandings that have arisen from previous conversations around this topic at past events. We agreed that at present the only way to perform upgrades between N and N+>=2 releases of OpenStack was to upgrade linearly through each major release, without skipping between the starting and target release of the upgrade. This is contrary to previous discussions on the topic where it had been suggested that releases could be skipped if DB migrations for these releases were applied in bulk later in the process. As projects within the community currently offer no such support for this it was agreed to continue to use the supported N to N+1 upgrade jumps, albeit in a minimal, offline way. The name skip-level upgrades has had an obvious role to play in the confusion here and as such the renaming of this effort was discussed at length. Various suggestions are listed on the pad but for the time being I'm going to stick with the basic `fast-forward upgrades` name (FFOU, OFF, BOFF, FFUD etc were all close behind). This removes any notion of releases being skipped and should hopefully avoid any further confusion in the future. Support by the projects for offline upgrades was then discussed with a recent Ironic issue [2] highlighted as an example where projects have required services to run before the upgrade could be considered complete. The additional requirement of ensuring both workloads and the data plane remain active during the upgrade was also then discussed. It was agreed that both the `supports-upgrades` [3] and `supports-accessible-upgrades` [4] tags should be updated to reflect these requirements for fast-forward upgrades. Given the above it was agreed that this new definition of what fast-forward upgrades are and the best practices associated with them should be clearly documented somewhere. Various operators in the room highlighted that they would like to see a high level document outline the steps required to achieve this, hopefully written by someone with past experience of running this type of upgrade. I failed to capture the names of the individuals who were interested in helping out here. If anyone is interested in helping out here please feel free to add your name to the actions either at the end of this mail or at the bottom of the pad. In the afternoon we reviewed the current efforts within the community to implement fast-forward upgrades, covering TripleO, Charms (Juju) and openstack-ansible. While this was insightful to many in the room there didn't appear to be any obvious areas of collaboration outside of sharing best practice and defining the high level flow of a fast-forward upgrade. Tuesday - NFV, SIG and actions -- Tuesday started with a discussion around NFV considerations with fast-forward upgrades. These ranged from the previously mentioned need for the data plane to remain active during the upgrade to the restricted nature of upgrades in NFV environments in terms of time and number of reboots. It was highlighted that there are some serious as yet unresolved bugs in Nova regarding the live migration of instances using SR-IOV devices. This currently makes the moving of workloads either prior to or during the upgrade particularly difficult. Rollbacks were also discussed and the need for any best practice documentation around fast-forward upgrades to include steps to allow the recovery of environments if things fail was also highlighted. We then revisited an idea from the first day of finding or creating a SIG for this effort to call home. It was highlighted that there was a suggestion in the packaging room to create a Deployment / Lifecycle SIG. After speaking with a few individuals later in the week I've taken the action to reach out on the openstack-sigs mailing list for further input. Finally, during a brief discussion on ways we could collaborate and share tooling for fast-forward upgrades a new tool to migrate configuration files between N to N+>=2 releases was introduced [5]. While interesting it was seen as a more generic utility that coul
[openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
My thanks again to everyone who attended and contributed to the skip-level upgrades track over the first two days of last weeks PTG. I've included a short summary of our discussions below with a list of agreed actions for Queens at the end. tl;dr s/skip-level/fast-forward/g https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades Monday - Define and rename -- During our first session [1] we briefly discussed the history of the skip-level upgrades effort within the community and the various misunderstandings that have arisen from previous conversations around this topic at past events. We agreed that at present the only way to perform upgrades between N and N+>=2 releases of OpenStack was to upgrade linearly through each major release, without skipping between the starting and target release of the upgrade. This is contrary to previous discussions on the topic where it had been suggested that releases could be skipped if DB migrations for these releases were applied in bulk later in the process. As projects within the community currently offer no such support for this it was agreed to continue to use the supported N to N+1 upgrade jumps, albeit in a minimal, offline way. The name skip-level upgrades has had an obvious role to play in the confusion here and as such the renaming of this effort was discussed at length. Various suggestions are listed on the pad but for the time being I'm going to stick with the basic `fast-forward upgrades` name (FFOU, OFF, BOFF, FFUD etc were all close behind). This removes any notion of releases being skipped and should hopefully avoid any further confusion in the future. Support by the projects for offline upgrades was then discussed with a recent Ironic issue [2] highlighted as an example where projects have required services to run before the upgrade could be considered complete. The additional requirement of ensuring both workloads and the data plane remain active during the upgrade was also then discussed. It was agreed that both the `supports-upgrades` [3] and `supports-accessible-upgrades` [4] tags should be updated to reflect these requirements for fast-forward upgrades. Given the above it was agreed that this new definition of what fast-forward upgrades are and the best practices associated with them should be clearly documented somewhere. Various operators in the room highlighted that they would like to see a high level document outline the steps required to achieve this, hopefully written by someone with past experience of running this type of upgrade. I failed to capture the names of the individuals who were interested in helping out here. If anyone is interested in helping out here please feel free to add your name to the actions either at the end of this mail or at the bottom of the pad. In the afternoon we reviewed the current efforts within the community to implement fast-forward upgrades, covering TripleO, Charms (Juju) and openstack-ansible. While this was insightful to many in the room there didn't appear to be any obvious areas of collaboration outside of sharing best practice and defining the high level flow of a fast-forward upgrade. Tuesday - NFV, SIG and actions -- Tuesday started with a discussion around NFV considerations with fast-forward upgrades. These ranged from the previously mentioned need for the data plane to remain active during the upgrade to the restricted nature of upgrades in NFV environments in terms of time and number of reboots. It was highlighted that there are some serious as yet unresolved bugs in Nova regarding the live migration of instances using SR-IOV devices. This currently makes the moving of workloads either prior to or during the upgrade particularly difficult. Rollbacks were also discussed and the need for any best practice documentation around fast-forward upgrades to include steps to allow the recovery of environments if things fail was also highlighted. We then revisited an idea from the first day of finding or creating a SIG for this effort to call home. It was highlighted that there was a suggestion in the packaging room to create a Deployment / Lifecycle SIG. After speaking with a few individuals later in the week I've taken the action to reach out on the openstack-sigs mailing list for further input. Finally, during a brief discussion on ways we could collaborate and share tooling for fast-forward upgrades a new tool to migrate configuration files between N to N+>=2 releases was introduced [5]. While interesting it was seen as a more generic utility that could also be used between N to N+1 upgrades. AFAIK the authors joined the Oslo room shortly after this session ended to gain more feedback from that team. Actions --- - Modify the `supports-upgrades`[3] and `supports-accessible-upgrades`[4] tags I have yet to look into the formal process around making changes to these tags but I will aim to make a start ASAP. - Find an Ops
