Re: [openstack-dev] [TC] Stein Goal Selection
I've been slowly working on building out and adding to the documentation about how to do things, but I can make that my top priority so that you all have a little more guidance. I'll try to get some patches out in the next week or so. Storyboard seems complicated but I think most of the mental hoops are just that you have the flexibility to manage and organize work however you'd like. You being both an individual and you being the project. Also, each project is so different (some use bps and specs, some ignore bps entirely, others use milestones, some just care about what bugs are new...) we didn't want to force a lot of required fields and whatnot on users. I can see how the flexibility can be a bit daunting though. Hopefully the docs I write will help clarify things. Also, that video does talk a little bit about usage at the end actually. Adam goes into different ways of using worklists and boards to organize things. Keep an eye out for my patches though :) -Kendall (diablo_rojo) On Fri, Jun 8, 2018 at 12:06 PM Matt Riedemann wrote: > On 6/8/2018 1:03 PM, Jay S Bryant wrote: > > Helps if I include the link to the video: > > > https://www.openstack.org/videos/boston-2017/storyboard-101-survival-guide-to-the-great-migration > > > > > > Hope that helps. > > Yeah I linked to that in my original email - that's about the migration, > not usage. I want to see stuff like what's the normal workflow for a new > user to storyboard, reporting bugs, linking those to gerrit changes, > multiple tasks, how to search for stuff (search was failing me big time > yesterday), etc. > > Also, I can't even add a 2nd task to an existing story without getting a > 500 transaction error from the DB, so that seems like a major scaling > issue if we're all going to be migrating. > > -- > > 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 > __ 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] [TC] Stein Goal Selection
On 6/8/2018 1:03 PM, Jay S Bryant wrote: Helps if I include the link to the video: https://www.openstack.org/videos/boston-2017/storyboard-101-survival-guide-to-the-great-migration Hope that helps. Yeah I linked to that in my original email - that's about the migration, not usage. I want to see stuff like what's the normal workflow for a new user to storyboard, reporting bugs, linking those to gerrit changes, multiple tasks, how to search for stuff (search was failing me big time yesterday), etc. Also, I can't even add a 2nd task to an existing story without getting a 500 transaction error from the DB, so that seems like a major scaling issue if we're all going to be migrating. -- 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] [TC] Stein Goal Selection
On 6/7/2018 5:48 PM, Matt Riedemann wrote: On 6/7/2018 3:25 PM, Kendall Nelson wrote: I know it doesn't fit the shiny user facing docket that was discussed at the Forum, but I do think its time we make migration official in some capacity as a release goal or some other way. Having migrated Ironic and having TripleO on the schedule for migration (as requested during the last goal discussion) in addition to having migrated Heat, Barbican and several others in the last few months we have reached the point that I think migration of the rest of the projects is attainable by the end of Stein. Thoughts? I haven't used it much, but it would be really nice if someone could record a modern 'how to storyboard' video for just basic usage/flows since most people are used to launchpad by now so dealing with an entirely new task tracker is not trivial (or at least, not something I want to spend a lot of time figuring out). I found: https://www.youtube.com/watch?v=b2vJ9G5pNb4 https://www.youtube.com/watch?v=n_PaKuN4Skk But those are a bit old. Helps if I include the link to the video: https://www.openstack.org/videos/boston-2017/storyboard-101-survival-guide-to-the-great-migration Hope that helps. Jay __ 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] [TC] Stein Goal Selection
On 6/7/2018 5:48 PM, Matt Riedemann wrote: On 6/7/2018 3:25 PM, Kendall Nelson wrote: I know it doesn't fit the shiny user facing docket that was discussed at the Forum, but I do think its time we make migration official in some capacity as a release goal or some other way. Having migrated Ironic and having TripleO on the schedule for migration (as requested during the last goal discussion) in addition to having migrated Heat, Barbican and several others in the last few months we have reached the point that I think migration of the rest of the projects is attainable by the end of Stein. Thoughts? I haven't used it much, but it would be really nice if someone could record a modern 'how to storyboard' video for just basic usage/flows since most people are used to launchpad by now so dealing with an entirely new task tracker is not trivial (or at least, not something I want to spend a lot of time figuring out). I found: https://www.youtube.com/watch?v=b2vJ9G5pNb4 https://www.youtube.com/watch?v=n_PaKuN4Skk But those are a bit old. Matt, The following presentation was done in Boston. If I remember correctly they covered some of the basics on how to use Storyboard. [1] I feel your pain on the migration. I have used it a bit and and it is kind of like a combination of Launchpad and Trello. I think once we start using it the learning curve won't be so bad. Jay __ 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] [TC] Stein Goal Selection
Sean McGinnis 於 2018年6月5日 週二 上午2:07寫道： > > Python 3 First > == > > One of the things brought up in the session was picking things that bring > excitement and are obvious benefits to deployers and users of OpenStack > services. While this one is maybe not as immediately obvious, I think this > is something that will end up helping deployers and also falls into the tech > debt reduction category that will help us move quicker long term. > > Python 2 is going away soon, so I think we need something to help compel folks > to work on making sure we are ready to transition. This will also be a good > point to help switch the mindset over to Python 3 being the default used > everywhere, with our Python 2 compatibility being just to continue legacy > support. > +1 on Python3 first goal I think it's great if we can start investigating how projects been doing with py3.5+. And to have a check job for py3.6 will be a nice start for this goal. If it's possible, our goal should match with what most users are facing. Mention 3.6 because of Ubuntu Artful and Fedora 26 use it by default (see [1] for more info). [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131193.html -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin __ 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] [TC] Stein Goal Selection
Matt Riedemann 於 2018年6月8日 週五 上午6:49寫道： > I haven't used it much, but it would be really nice if someone could > record a modern 'how to storyboard' video for just basic usage/flows > since most people are used to launchpad by now so dealing with an > entirely new task tracker is not trivial (or at least, not something I > want to spend a lot of time figuring out). > > I found: > > https://www.youtube.com/watch?v=b2vJ9G5pNb4 > > https://www.youtube.com/watch?v=n_PaKuN4Skk > > But those are a bit old. > I create an Etherpad to collect Q on Migrate from Launchpad to StoryBoard for Heat (most information were general). Hope this helps https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info > -- > > 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 -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin __ 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] [TC] Stein Goal Selection
Kendall Nelson 於 2018年6月8日 週五 上午4:26寫道： > > I think that these two goals definitely fit the criteria we discussed in Vancouver during the S Release Goal Forum Session. I know Storyboard Migration was also mentioned after I had to dip out to another session so I wanted to follow up on that. > +1. To migrate to StoryBoard do seems like a good way to go. Heat just moved to StoryBoard, so there is no much long-term running experiences to share about, but it does look like a good way to target the piece which we been missing of. A workflow to connect users, ops, and developers (within Launchpad, we only care about bugs, and what generate that bug? well...we don't care). With Story + Task-oriented things can change (To me this is shiny). For migrate experience, the migration is quick, so if there is no project really really only can survive with Launchpad, I think there is no blocker for this goal. Also, it's quite convenient to target your story with your old bug, since your story id is your bug id. Since it might be difficult for all project directly migrated to it, IMO we should at least have a potential goal for T release (or a long-term goal for Stein?). Or we can directly set this as a Stein goal as well. Why? Because of the very first Story ID actually started from 200(and as I mentioned, after migrating, your story id is exactly your bug id ). So once we generate bug with ID 200, things will become interesting (and hard to migrate). Current is 1775759, so one or two years I guess? To interpreted `might be difficult` above, The overall experience is great, some small things should get improve: - I can't tell if current story is already reported or not. There is no way to filter stories and checking conflict if there is. - Things going slow if we try to use Board in StoryBoard to filter out a great number of stories (like when I need to see all `High Priority` tagged stories) - Needs better documentation, In Heat we create an Etherpad to describe and collect Q on how people can better adopt StoryBoard. It will be great if teams can directly get this information. Overall, I think this is a nice goal, and it's actually painless to migrate. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin __ 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] [TC] Stein Goal Selection
On 6/7/2018 3:25 PM, Kendall Nelson wrote: I know it doesn't fit the shiny user facing docket that was discussed at the Forum, but I do think its time we make migration official in some capacity as a release goal or some other way. Having migrated Ironic and having TripleO on the schedule for migration (as requested during the last goal discussion) in addition to having migrated Heat, Barbican and several others in the last few months we have reached the point that I think migration of the rest of the projects is attainable by the end of Stein. Thoughts? I haven't used it much, but it would be really nice if someone could record a modern 'how to storyboard' video for just basic usage/flows since most people are used to launchpad by now so dealing with an entirely new task tracker is not trivial (or at least, not something I want to spend a lot of time figuring out). I found: https://www.youtube.com/watch?v=b2vJ9G5pNb4 https://www.youtube.com/watch?v=n_PaKuN4Skk But those are a bit old. -- 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] [TC] Stein Goal Selection
On 2018-06-07 14:19:41 -0700 (-0700), Clark Boylan wrote: [...] > We stopped following latest Ubuntu when they dropped non LTS > support to 9 months. What we do have are suse tumbleweed images > which should get us brand new everything in a rolling fashion. If > people are interested in this type of work I'd probably start > there. Though following up on the work already started to get debian-sid images wouldn't hurt. I know people think Sid is constantly broken, but I run it on my workstation and all my portable devices (and have for a couple decades) so I'm fairly confident the minimal install image build isn't likely to actually break with any significant frequency once we get it working. -- Jeremy Stanley 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] [TC] Stein Goal Selection
On Thu, Jun 7, 2018, at 1:53 PM, Thomas Goirand wrote: > On 06/04/2018 08:59 PM, Ivan Kolodyazhny wrote: > > I hope we'll have Ubuntu 18.04 LTS on our gates for this activity soon. > > It becomes > > important not only for developers but for operators and vendors too. > > By the time the project will be gating on Python 3.6, most likely > there's going to be 3.7 or even 3.8 in Debian Sid, and I'll get all the > broken stuff alone again... Can't we try to get Sid in the gate, at > least in non-voting mode, so we get to see problems early rather than > late? As developers, we should always aim for the future, and Bionic > should already be considered the past release to maintain, rather than > the one to focus on. If we can't get Sid, then at least should we > consider the non-LTS (always latest) Ubuntu releases? We stopped following latest Ubuntu when they dropped non LTS support to 9 months. What we do have are suse tumbleweed images which should get us brand new everything in a rolling fashion. If people are interested in this type of work I'd probably start there. Clark __ 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] [TC] Stein Goal Selection
On 06/04/2018 08:59 PM, Ivan Kolodyazhny wrote: > I hope we'll have Ubuntu 18.04 LTS on our gates for this activity soon. > It becomes > important not only for developers but for operators and vendors too. By the time the project will be gating on Python 3.6, most likely there's going to be 3.7 or even 3.8 in Debian Sid, and I'll get all the broken stuff alone again... Can't we try to get Sid in the gate, at least in non-voting mode, so we get to see problems early rather than late? As developers, we should always aim for the future, and Bionic should already be considered the past release to maintain, rather than the one to focus on. If we can't get Sid, then at least should we consider the non-LTS (always latest) Ubuntu releases? Cheers, Thomas Goirand (zigo) __ 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] [TC] Stein Goal Selection
Hello :) I think that these two goals definitely fit the criteria we discussed in Vancouver during the S Release Goal Forum Session. I know Storyboard Migration was also mentioned after I had to dip out to another session so I wanted to follow up on that. I know it doesn't fit the shiny user facing docket that was discussed at the Forum, but I do think its time we make migration official in some capacity as a release goal or some other way. Having migrated Ironic and having TripleO on the schedule for migration (as requested during the last goal discussion) in addition to having migrated Heat, Barbican and several others in the last few months we have reached the point that I think migration of the rest of the projects is attainable by the end of Stein. Thoughts? -Kendall (diablo_rojo) On Mon, Jun 4, 2018 at 11:08 AM Sean McGinnis wrote: > Hi everyone, > > This is to continue the discussion of the goal selection for the Stein > release. > I had previously sent out a recap of our discussion at the Forum here: > > http://lists.openstack.org/pipermail/openstack-dev/2018-May/130999.html > > Now we need to actually narrow things down and pick a couple goals. > > Strawman > > > Just to set a starting point for debate, I propose the following two as > goals > for Stein: > > - Cold Upgade Support > - Python 3 first > > As a reminder of other ideas, here is the link to the backlog of goal ideas > we've kept so far: > > https://etherpad.openstack.org/p/community-goals > > Feel free to add more to that list, and if you have been involved in any > of the > things that have been completed there, please remove things you don't think > should still be there. > > This is by no means an exhaustive list of what we could or should do for > goals. > > With that, I'll go over the choices that I've proposed for the strawman. > > Python 3 First > == > > One of the things brought up in the session was picking things that bring > excitement and are obvious benefits to deployers and users of OpenStack > services. While this one is maybe not as immediately obvious, I think this > is something that will end up helping deployers and also falls into the > tech > debt reduction category that will help us move quicker long term. > > Python 2 is going away soon, so I think we need something to help compel > folks > to work on making sure we are ready to transition. This will also be a good > point to help switch the mindset over to Python 3 being the default used > everywhere, with our Python 2 compatibility being just to continue legacy > support. > > Cold Upgrade Support > > > The other suggestion in the Forum session related to upgrades was the > addition > of "upgrade check" CLIs for each project, and I was tempted to suggest > that as > my second strawman choice. For some projects that would be a very minimal > or > NOOP check, so it would probably be easy to complete the goal. But > ultimately > what I think would bring the most value would be the work on supporting > cold > upgrade, even if it will be more of a stretch for some projects to > accomplish. > > Upgrades have been a major focus of discussion lately, especially as our > operators have been trying to get closer to the latest work upstream. This > has > been an ongoing challenge. > > There has also been a lot of talk about LTS releases. We've landed on fast > forward upgrade to get between several releases, but I think improving > upgrades > eases the way both for easier and more frequent upgrades and also getting > to > the point some day where maybe we can think about upgrading over several > releases to be able to do something like an LTS to LTS upgrade. > > Neither one of these upgrade goals really has a clearly defined plan that > projects can pick up now and start working on, but I think with those > involved > in these areas we should be able to come up with a perscriptive plan for > projects to follow. > > And it would really move our fast forward upgrade story forward. > > Next Steps > == > > I'm hoping with a strawman proposal we have a basis for debating the > merits of > these and getting closer to being able to officially select Stein goals. We > still have some time, but I would like to avoid making late-cycle > selections so > teams can start planning ahead for what will need to be done in Stein. > > Please feel free to promote other ideas for goals. That would be a good > way for > us to weigh the pro's and con's between these and whatever else you have in > mind. Then hopefully we can come to some consensus and work towards clearly > defining what needs to be done and getting things well documented for > teams to > pick up as soon as they wrap up Rocky (or sooner). > > --- > Sean (smcginnis) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe:
Re: [openstack-dev] [TC] Stein Goal Selection
On 06/07/2018 09:39 AM, Matt Riedemann wrote: On 6/5/2018 9:14 AM, Doug Hellmann wrote: In the past when we've had questions about how broadly a goal is going to affect projects, we did a little data collection work up front. Maybe that's the next step for this one? Does someone want to volunteer to go around and talk to some of the project teams that are likely candidates for these sorts of upgrade blockers to start making lists? I figured that if the upgrade status check CLI goal was ever given serious consideration, I'd likely be the champion since I wrote the nova-status CLI and do a lot of the maintenance and updates to it. So unless others are interested in this, you can sign me up, but at the moment I'm pretty swamped with nova development stuff so I can't make any promises on making quick progress. Excellent, thanks Matt. Keep in mind that being the champion for a goal does not necessarily mean you will be the one doing all the work. The goals just need someone that can help facilitate things like communication and education to the affected teams and keep an eye on the progress. __ 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] [TC] Stein Goal Selection
On 6/5/2018 9:14 AM, Doug Hellmann wrote: In the past when we've had questions about how broadly a goal is going to affect projects, we did a little data collection work up front. Maybe that's the next step for this one? Does someone want to volunteer to go around and talk to some of the project teams that are likely candidates for these sorts of upgrade blockers to start making lists? I figured that if the upgrade status check CLI goal was ever given serious consideration, I'd likely be the champion since I wrote the nova-status CLI and do a lot of the maintenance and updates to it. So unless others are interested in this, you can sign me up, but at the moment I'm pretty swamped with nova development stuff so I can't make any promises on making quick progress. -- 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] [TC] Stein Goal Selection
Excerpts from Sean McGinnis's message of 2018-06-05 07:26:27 -0500: > On Mon, Jun 04, 2018 at 06:44:15PM -0500, Matt Riedemann wrote: > > On 6/4/2018 5:13 PM, Sean McGinnis wrote: > > > Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would > > > check here. We don't have to see if placement has been set up or if cell0 > > > has been configured. Maybe once we have the facility in place we would > > > find some things worth checking, but at present I don't know what that > > > would be. > > > > Here is an example from the Cinder Queens upgrade release notes: > > > > "RBD/Ceph backends should adjust max_over_subscription_ratio to take into > > account that the driver is no longer reporting volume’s physical usage but > > it’s provisioned size." > > > > I'm assuming you could check if rbd is configured as a storage backend and > > if so, is max_over_subscription_ratio set? If not, is it fatal? Does the > > operator need to configure it before upgrading to Rocky? Or is it something > > they should consider but don't necessary have to do - if that, there is a > > 'WARNING' status for those types of things. > > > > Things that are good candidates for automating are anything that would stop > > the cinder-volume service from starting, or things that require data > > migrations before you can roll forward. In nova we've had blocking DB schema > > migrations for stuff like this which basically mean "you haven't run the > > online data migrations CLI yet so we're not letting you go any further until > > your homework is done". > > > > Thanks, I suppose we probably could find some things to at least WARN on. > Maybe > that would be useful. > > I suppose as far as a series goal goes, even if each project doesn't come up > with a comprehensive set of checks, this would be a known thing deployers > could > use and potentially build some additional tooling around. This could be a good > win for the overall ease of upgrade story. > > > Like I said, it's not black and white, but chances are good there are things > > that fall into these categories. In the past when we've had questions about how broadly a goal is going to affect projects, we did a little data collection work up front. Maybe that's the next step for this one? Does someone want to volunteer to go around and talk to some of the project teams that are likely candidates for these sorts of upgrade blockers to start making lists? Doug > > > > -- > > > > 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] [TC] Stein Goal Selection
On Mon, Jun 04, 2018 at 06:44:15PM -0500, Matt Riedemann wrote: > On 6/4/2018 5:13 PM, Sean McGinnis wrote: > > Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would > > check here. We don't have to see if placement has been set up or if cell0 > > has been configured. Maybe once we have the facility in place we would > > find some things worth checking, but at present I don't know what that > > would be. > > Here is an example from the Cinder Queens upgrade release notes: > > "RBD/Ceph backends should adjust max_over_subscription_ratio to take into > account that the driver is no longer reporting volume’s physical usage but > it’s provisioned size." > > I'm assuming you could check if rbd is configured as a storage backend and > if so, is max_over_subscription_ratio set? If not, is it fatal? Does the > operator need to configure it before upgrading to Rocky? Or is it something > they should consider but don't necessary have to do - if that, there is a > 'WARNING' status for those types of things. > > Things that are good candidates for automating are anything that would stop > the cinder-volume service from starting, or things that require data > migrations before you can roll forward. In nova we've had blocking DB schema > migrations for stuff like this which basically mean "you haven't run the > online data migrations CLI yet so we're not letting you go any further until > your homework is done". > Thanks, I suppose we probably could find some things to at least WARN on. Maybe that would be useful. I suppose as far as a series goal goes, even if each project doesn't come up with a comprehensive set of checks, this would be a known thing deployers could use and potentially build some additional tooling around. This could be a good win for the overall ease of upgrade story. > Like I said, it's not black and white, but chances are good there are things > that fall into these categories. > > -- > > 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] [TC] Stein Goal Selection
On 6/4/2018 5:13 PM, Sean McGinnis wrote: Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would check here. We don't have to see if placement has been set up or if cell0 has been configured. Maybe once we have the facility in place we would find some things worth checking, but at present I don't know what that would be. Here is an example from the Cinder Queens upgrade release notes: "RBD/Ceph backends should adjust max_over_subscription_ratio to take into account that the driver is no longer reporting volume’s physical usage but it’s provisioned size." I'm assuming you could check if rbd is configured as a storage backend and if so, is max_over_subscription_ratio set? If not, is it fatal? Does the operator need to configure it before upgrading to Rocky? Or is it something they should consider but don't necessary have to do - if that, there is a 'WARNING' status for those types of things. Things that are good candidates for automating are anything that would stop the cinder-volume service from starting, or things that require data migrations before you can roll forward. In nova we've had blocking DB schema migrations for stuff like this which basically mean "you haven't run the online data migrations CLI yet so we're not letting you go any further until your homework is done". Like I said, it's not black and white, but chances are good there are things that fall into these categories. -- 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] [TC] Stein Goal Selection
Adding back the openstack-operators list that Matt added. On 06/04/2018 05:13 PM, Sean McGinnis wrote: On 06/04/2018 04:17 PM, Doug Hellmann wrote: Excerpts from Matt Riedemann's message of 2018-06-04 15:38:48 -0500: On 6/4/2018 1:07 PM, Sean McGinnis wrote: Python 3 First == One of the things brought up in the session was picking things that bring excitement and are obvious benefits to deployers and users of OpenStack services. While this one is maybe not as immediately obvious, I think this is something that will end up helping deployers and also falls into the tech debt reduction category that will help us move quicker long term. Python 2 is going away soon, so I think we need something to help compel folks to work on making sure we are ready to transition. This will also be a good point to help switch the mindset over to Python 3 being the default used everywhere, with our Python 2 compatibility being just to continue legacy support. I still don't really know what this goal means - we have python 3 support across the projects for the most part don't we? Based on that, this doesn't seem like much to take an entire "goal slot" for the release. We still run docs, linters, functional tests, and other jobs under python 2 by default. Perhaps a better framing would be to call this "Python 3 by default", because the point is to change all of those jobs to use Python 3, and to set up all future jobs using Python 3 unless we specifically need to run them under Python 2. This seems like a small thing, but when we did it for Oslo we did find code issues because the linters apply different rules and we did find documentation build issues. The fixes were all straightforward, so I don't expect it to mean a lot of work, but it's more than a single patch per project. I also think using a goal is a good way to start shifting the mindset of the contributor base into this new perspective. Yes, that's probably a better way to word it to properly convey the goal. Basically, all things running under Python3, project code and tooling, as the default unless specifically geared towards Python2. Cold Upgrade Support The other suggestion in the Forum session related to upgrades was the addition of "upgrade check" CLIs for each project, and I was tempted to suggest that as my second strawman choice. For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal. But ultimately what I think would bring the most value would be the work on supporting cold upgrade, even if it will be more of a stretch for some projects to accomplish. I think you might be mixing two concepts here. Not so much mixing as discussing the two and the reason why I personally thought the one was a better goal, if you read through what was said about it. The cold upgrade support, per my understanding, is about getting the assert:supports-upgrade tag: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html Which to me basically means the project runs a grenade job. There was discussion in the room about grenade not being a great tool for all projects, but no one is working on a replacement for that, so I don't think it's really justification at this point for *not* making it a goal. The "upgrade check" CLIs is a different thing though, which is more about automating as much of the upgrade release notes as possible. See the nova docs for examples on how we have used it: https://docs.openstack.org/nova/latest/cli/nova-status.html I'm not sure what projects you had in mind when you said, "For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal." I would expect that projects aren't meeting the goal if they are noop'ing everything. But what can be automated like this isn't necessarily black and white either. What I remember from the discussion in the room was that not all projects are going to have anything to do by hand that would block an upgrade, but we still want all projects to have the test command. That means many of those commands could potentially be no-ops, right? Unless they're all going to do something like verify the schema has been updated somehow? Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would check here. We don't have to see if placement has been set up or if cell0 has been configured. Maybe once we have the facility in place we would find some things worth checking, but at present I don't know what that would be. Which also makes me wonder, should this be an oslo thing that projects just plug in to for their specific checks? Upgrades have been a major focus of discussion lately, especially as our operators have been trying to get closer to the latest work upstream. This has been an ongoing challenge. There has also been a lot of talk about LTS releases. We've landed on fast forward upgrade to get between
Re: [openstack-dev] [TC] Stein Goal Selection
On 06/04/2018 04:17 PM, Doug Hellmann wrote: Excerpts from Matt Riedemann's message of 2018-06-04 15:38:48 -0500: On 6/4/2018 1:07 PM, Sean McGinnis wrote: Python 3 First == One of the things brought up in the session was picking things that bring excitement and are obvious benefits to deployers and users of OpenStack services. While this one is maybe not as immediately obvious, I think this is something that will end up helping deployers and also falls into the tech debt reduction category that will help us move quicker long term. Python 2 is going away soon, so I think we need something to help compel folks to work on making sure we are ready to transition. This will also be a good point to help switch the mindset over to Python 3 being the default used everywhere, with our Python 2 compatibility being just to continue legacy support. I still don't really know what this goal means - we have python 3 support across the projects for the most part don't we? Based on that, this doesn't seem like much to take an entire "goal slot" for the release. We still run docs, linters, functional tests, and other jobs under python 2 by default. Perhaps a better framing would be to call this "Python 3 by default", because the point is to change all of those jobs to use Python 3, and to set up all future jobs using Python 3 unless we specifically need to run them under Python 2. This seems like a small thing, but when we did it for Oslo we did find code issues because the linters apply different rules and we did find documentation build issues. The fixes were all straightforward, so I don't expect it to mean a lot of work, but it's more than a single patch per project. I also think using a goal is a good way to start shifting the mindset of the contributor base into this new perspective. Yes, that's probably a better way to word it to properly convey the goal. Basically, all things running under Python3, project code and tooling, as the default unless specifically geared towards Python2. Cold Upgrade Support The other suggestion in the Forum session related to upgrades was the addition of "upgrade check" CLIs for each project, and I was tempted to suggest that as my second strawman choice. For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal. But ultimately what I think would bring the most value would be the work on supporting cold upgrade, even if it will be more of a stretch for some projects to accomplish. I think you might be mixing two concepts here. Not so much mixing as discussing the two and the reason why I personally thought the one was a better goal, if you read through what was said about it. The cold upgrade support, per my understanding, is about getting the assert:supports-upgrade tag: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html Which to me basically means the project runs a grenade job. There was discussion in the room about grenade not being a great tool for all projects, but no one is working on a replacement for that, so I don't think it's really justification at this point for *not* making it a goal. The "upgrade check" CLIs is a different thing though, which is more about automating as much of the upgrade release notes as possible. See the nova docs for examples on how we have used it: https://docs.openstack.org/nova/latest/cli/nova-status.html I'm not sure what projects you had in mind when you said, "For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal." I would expect that projects aren't meeting the goal if they are noop'ing everything. But what can be automated like this isn't necessarily black and white either. What I remember from the discussion in the room was that not all projects are going to have anything to do by hand that would block an upgrade, but we still want all projects to have the test command. That means many of those commands could potentially be no-ops, right? Unless they're all going to do something like verify the schema has been updated somehow? Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would check here. We don't have to see if placement has been set up or if cell0 has been configured. Maybe once we have the facility in place we would find some things worth checking, but at present I don't know what that would be. Which also makes me wonder, should this be an oslo thing that projects just plug in to for their specific checks? Upgrades have been a major focus of discussion lately, especially as our operators have been trying to get closer to the latest work upstream. This has been an ongoing challenge. There has also been a lot of talk about LTS releases. We've landed on fast forward upgrade to get between several releases, but I think improving upgrades eases the way both for easier and more frequent upgrades and also getting to the point
Re: [openstack-dev] [TC] Stein Goal Selection
Excerpts from Matt Riedemann's message of 2018-06-04 15:38:48 -0500: > On 6/4/2018 1:07 PM, Sean McGinnis wrote: > > Python 3 First > > == > > > > One of the things brought up in the session was picking things that bring > > excitement and are obvious benefits to deployers and users of OpenStack > > services. While this one is maybe not as immediately obvious, I think this > > is something that will end up helping deployers and also falls into the tech > > debt reduction category that will help us move quicker long term. > > > > Python 2 is going away soon, so I think we need something to help compel > > folks > > to work on making sure we are ready to transition. This will also be a good > > point to help switch the mindset over to Python 3 being the default used > > everywhere, with our Python 2 compatibility being just to continue legacy > > support. > > I still don't really know what this goal means - we have python 3 > support across the projects for the most part don't we? Based on that, > this doesn't seem like much to take an entire "goal slot" for the release. We still run docs, linters, functional tests, and other jobs under python 2 by default. Perhaps a better framing would be to call this "Python 3 by default", because the point is to change all of those jobs to use Python 3, and to set up all future jobs using Python 3 unless we specifically need to run them under Python 2. This seems like a small thing, but when we did it for Oslo we did find code issues because the linters apply different rules and we did find documentation build issues. The fixes were all straightforward, so I don't expect it to mean a lot of work, but it's more than a single patch per project. I also think using a goal is a good way to start shifting the mindset of the contributor base into this new perspective. > > > > Cold Upgrade Support > > > > > > The other suggestion in the Forum session related to upgrades was the > > addition > > of "upgrade check" CLIs for each project, and I was tempted to suggest that > > as > > my second strawman choice. For some projects that would be a very minimal or > > NOOP check, so it would probably be easy to complete the goal. But > > ultimately > > what I think would bring the most value would be the work on supporting cold > > upgrade, even if it will be more of a stretch for some projects to > > accomplish. > > I think you might be mixing two concepts here. > > The cold upgrade support, per my understanding, is about getting the > assert:supports-upgrade tag: > > https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html > > Which to me basically means the project runs a grenade job. There was > discussion in the room about grenade not being a great tool for all > projects, but no one is working on a replacement for that, so I don't > think it's really justification at this point for *not* making it a goal. > > The "upgrade check" CLIs is a different thing though, which is more > about automating as much of the upgrade release notes as possible. See > the nova docs for examples on how we have used it: > > https://docs.openstack.org/nova/latest/cli/nova-status.html > > I'm not sure what projects you had in mind when you said, "For some > projects that would be a very minimal or NOOP check, so it would > probably be easy to complete the goal." I would expect that projects > aren't meeting the goal if they are noop'ing everything. But what can be > automated like this isn't necessarily black and white either. What I remember from the discussion in the room was that not all projects are going to have anything to do by hand that would block an upgrade, but we still want all projects to have the test command. That means many of those commands could potentially be no-ops, right? Unless they're all going to do something like verify the schema has been updated somehow? > > > > > Upgrades have been a major focus of discussion lately, especially as our > > operators have been trying to get closer to the latest work upstream. This > > has > > been an ongoing challenge. > > > > There has also been a lot of talk about LTS releases. We've landed on fast > > forward upgrade to get between several releases, but I think improving > > upgrades > > eases the way both for easier and more frequent upgrades and also getting to > > the point some day where maybe we can think about upgrading over several > > releases to be able to do something like an LTS to LTS upgrade. > > > > Neither one of these upgrade goals really has a clearly defined plan that > > projects can pick up now and start working on, but I think with those > > involved > > in these areas we should be able to come up with a perscriptive plan for > > projects to follow. > > > > And it would really move our fast forward upgrade story forward. > > Agreed. In the FFU Forum session at the summit I mentioned the > 'nova-status upgrade check' CLI
Re: [openstack-dev] [TC] Stein Goal Selection
+openstack-operators since we need to have more operator feedback in our community-wide goals decisions. +Melvin as my elected user committee person for the same reasons as adding operators into the discussion. On 6/4/2018 3:38 PM, Matt Riedemann wrote: On 6/4/2018 1:07 PM, Sean McGinnis wrote: Python 3 First == One of the things brought up in the session was picking things that bring excitement and are obvious benefits to deployers and users of OpenStack services. While this one is maybe not as immediately obvious, I think this is something that will end up helping deployers and also falls into the tech debt reduction category that will help us move quicker long term. Python 2 is going away soon, so I think we need something to help compel folks to work on making sure we are ready to transition. This will also be a good point to help switch the mindset over to Python 3 being the default used everywhere, with our Python 2 compatibility being just to continue legacy support. I still don't really know what this goal means - we have python 3 support across the projects for the most part don't we? Based on that, this doesn't seem like much to take an entire "goal slot" for the release. Cold Upgrade Support The other suggestion in the Forum session related to upgrades was the addition of "upgrade check" CLIs for each project, and I was tempted to suggest that as my second strawman choice. For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal. But ultimately what I think would bring the most value would be the work on supporting cold upgrade, even if it will be more of a stretch for some projects to accomplish. I think you might be mixing two concepts here. The cold upgrade support, per my understanding, is about getting the assert:supports-upgrade tag: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html Which to me basically means the project runs a grenade job. There was discussion in the room about grenade not being a great tool for all projects, but no one is working on a replacement for that, so I don't think it's really justification at this point for *not* making it a goal. The "upgrade check" CLIs is a different thing though, which is more about automating as much of the upgrade release notes as possible. See the nova docs for examples on how we have used it: https://docs.openstack.org/nova/latest/cli/nova-status.html I'm not sure what projects you had in mind when you said, "For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal." I would expect that projects aren't meeting the goal if they are noop'ing everything. But what can be automated like this isn't necessarily black and white either. Upgrades have been a major focus of discussion lately, especially as our operators have been trying to get closer to the latest work upstream. This has been an ongoing challenge. There has also been a lot of talk about LTS releases. We've landed on fast forward upgrade to get between several releases, but I think improving upgrades eases the way both for easier and more frequent upgrades and also getting to the point some day where maybe we can think about upgrading over several releases to be able to do something like an LTS to LTS upgrade. Neither one of these upgrade goals really has a clearly defined plan that projects can pick up now and start working on, but I think with those involved in these areas we should be able to come up with a perscriptive plan for projects to follow. And it would really move our fast forward upgrade story forward. Agreed. In the FFU Forum session at the summit I mentioned the 'nova-status upgrade check' CLI and a lot of people in the room had never heard of it because they are still on Mitaka before we added that CLI (new in Ocata). But they sounded really interested in it and said they wished other projects were doing that to help ease upgrades so they won't be stuck on older unmaintained releases for so long. So anything we can do to improve upgrades, including our testing for them, will help make FFU better. Next Steps == I'm hoping with a strawman proposal we have a basis for debating the merits of these and getting closer to being able to officially select Stein goals. We still have some time, but I would like to avoid making late-cycle selections so teams can start planning ahead for what will need to be done in Stein. Please feel free to promote other ideas for goals. That would be a good way for us to weigh the pro's and con's between these and whatever else you have in mind. Then hopefully we can come to some consensus and work towards clearly defining what needs to be done and getting things well documented for teams to pick up as soon as they wrap up Rocky (or sooner). I still want to lobby for a
Re: [openstack-dev] [TC] Stein Goal Selection
On 6/4/2018 1:07 PM, Sean McGinnis wrote: Python 3 First == One of the things brought up in the session was picking things that bring excitement and are obvious benefits to deployers and users of OpenStack services. While this one is maybe not as immediately obvious, I think this is something that will end up helping deployers and also falls into the tech debt reduction category that will help us move quicker long term. Python 2 is going away soon, so I think we need something to help compel folks to work on making sure we are ready to transition. This will also be a good point to help switch the mindset over to Python 3 being the default used everywhere, with our Python 2 compatibility being just to continue legacy support. I still don't really know what this goal means - we have python 3 support across the projects for the most part don't we? Based on that, this doesn't seem like much to take an entire "goal slot" for the release. Cold Upgrade Support The other suggestion in the Forum session related to upgrades was the addition of "upgrade check" CLIs for each project, and I was tempted to suggest that as my second strawman choice. For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal. But ultimately what I think would bring the most value would be the work on supporting cold upgrade, even if it will be more of a stretch for some projects to accomplish. I think you might be mixing two concepts here. The cold upgrade support, per my understanding, is about getting the assert:supports-upgrade tag: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html Which to me basically means the project runs a grenade job. There was discussion in the room about grenade not being a great tool for all projects, but no one is working on a replacement for that, so I don't think it's really justification at this point for *not* making it a goal. The "upgrade check" CLIs is a different thing though, which is more about automating as much of the upgrade release notes as possible. See the nova docs for examples on how we have used it: https://docs.openstack.org/nova/latest/cli/nova-status.html I'm not sure what projects you had in mind when you said, "For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal." I would expect that projects aren't meeting the goal if they are noop'ing everything. But what can be automated like this isn't necessarily black and white either. Upgrades have been a major focus of discussion lately, especially as our operators have been trying to get closer to the latest work upstream. This has been an ongoing challenge. There has also been a lot of talk about LTS releases. We've landed on fast forward upgrade to get between several releases, but I think improving upgrades eases the way both for easier and more frequent upgrades and also getting to the point some day where maybe we can think about upgrading over several releases to be able to do something like an LTS to LTS upgrade. Neither one of these upgrade goals really has a clearly defined plan that projects can pick up now and start working on, but I think with those involved in these areas we should be able to come up with a perscriptive plan for projects to follow. And it would really move our fast forward upgrade story forward. Agreed. In the FFU Forum session at the summit I mentioned the 'nova-status upgrade check' CLI and a lot of people in the room had never heard of it because they are still on Mitaka before we added that CLI (new in Ocata). But they sounded really interested in it and said they wished other projects were doing that to help ease upgrades so they won't be stuck on older unmaintained releases for so long. So anything we can do to improve upgrades, including our testing for them, will help make FFU better. Next Steps == I'm hoping with a strawman proposal we have a basis for debating the merits of these and getting closer to being able to officially select Stein goals. We still have some time, but I would like to avoid making late-cycle selections so teams can start planning ahead for what will need to be done in Stein. Please feel free to promote other ideas for goals. That would be a good way for us to weigh the pro's and con's between these and whatever else you have in mind. Then hopefully we can come to some consensus and work towards clearly defining what needs to be done and getting things well documented for teams to pick up as soon as they wrap up Rocky (or sooner). I still want to lobby for a push to move off the old per-project CLIs and close the gap on using python-openstackclient CLI for everything, but I'm unclear on what the roadmap is for the major refactor with the SDK Monty was talking about in Vancouver. From a new user perspective, the 2000 individual CLIs to get
Re: [openstack-dev] [TC] Stein Goal Selection
Hi Sean, These goals look reasonable for me. On Mon, Jun 4, 2018 at 9:07 PM, Sean McGinnis wrote: > Hi everyone, > > This is to continue the discussion of the goal selection for the Stein > release. > I had previously sent out a recap of our discussion at the Forum here: > > http://lists.openstack.org/pipermail/openstack-dev/2018-May/130999.html > > Now we need to actually narrow things down and pick a couple goals. > > Strawman > > > Just to set a starting point for debate, I propose the following two as > goals > for Stein: > > - Cold Upgade Support > - Python 3 first > > As a reminder of other ideas, here is the link to the backlog of goal ideas > we've kept so far: > > https://etherpad.openstack.org/p/community-goals > > Feel free to add more to that list, and if you have been involved in any > of the > things that have been completed there, please remove things you don't think > should still be there. > > This is by no means an exhaustive list of what we could or should do for > goals. > > With that, I'll go over the choices that I've proposed for the strawman. > > Python 3 First > == > > One of the things brought up in the session was picking things that bring > excitement and are obvious benefits to deployers and users of OpenStack > services. While this one is maybe not as immediately obvious, I think this > is something that will end up helping deployers and also falls into the > tech > debt reduction category that will help us move quicker long term. > > Python 2 is going away soon, so I think we need something to help compel > folks > to work on making sure we are ready to transition. This will also be a good > point to help switch the mindset over to Python 3 being the default used > everywhere, with our Python 2 compatibility being just to continue legacy > support. > I hope we'll have Ubuntu 18.04 LTS on our gates for this activity soon. It becomes important not only for developers but for operators and vendors too. > Cold Upgrade Support > > > The other suggestion in the Forum session related to upgrades was the > addition > of "upgrade check" CLIs for each project, and I was tempted to suggest > that as > my second strawman choice. For some projects that would be a very minimal > or > NOOP check, so it would probably be easy to complete the goal. But > ultimately > what I think would bring the most value would be the work on supporting > cold > upgrade, even if it will be more of a stretch for some projects to > accomplish. > > Upgrades have been a major focus of discussion lately, especially as our > operators have been trying to get closer to the latest work upstream. This > has > been an ongoing challenge. > > A big +1 from my side on it. There has also been a lot of talk about LTS releases. We've landed on fast > forward upgrade to get between several releases, but I think improving > upgrades > eases the way both for easier and more frequent upgrades and also getting > to > the point some day where maybe we can think about upgrading over several > releases to be able to do something like an LTS to LTS upgrade. > > Neither one of these upgrade goals really has a clearly defined plan that > projects can pick up now and start working on, but I think with those > involved > in these areas we should be able to come up with a perscriptive plan for > projects to follow. > > And it would really move our fast forward upgrade story forward. > > Next Steps > == > > I'm hoping with a strawman proposal we have a basis for debating the > merits of > these and getting closer to being able to officially select Stein goals. We > still have some time, but I would like to avoid making late-cycle > selections so > teams can start planning ahead for what will need to be done in Stein. > > Please feel free to promote other ideas for goals. That would be a good > way for > us to weigh the pro's and con's between these and whatever else you have in > mind. Then hopefully we can come to some consensus and work towards clearly > defining what needs to be done and getting things well documented for > teams to > pick up as soon as they wrap up Rocky (or sooner). > > --- > Sean (smcginnis) > > __ > 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 > __ 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
[openstack-dev] [TC] Stein Goal Selection
Hi everyone, This is to continue the discussion of the goal selection for the Stein release. I had previously sent out a recap of our discussion at the Forum here: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130999.html Now we need to actually narrow things down and pick a couple goals. Strawman Just to set a starting point for debate, I propose the following two as goals for Stein: - Cold Upgade Support - Python 3 first As a reminder of other ideas, here is the link to the backlog of goal ideas we've kept so far: https://etherpad.openstack.org/p/community-goals Feel free to add more to that list, and if you have been involved in any of the things that have been completed there, please remove things you don't think should still be there. This is by no means an exhaustive list of what we could or should do for goals. With that, I'll go over the choices that I've proposed for the strawman. Python 3 First == One of the things brought up in the session was picking things that bring excitement and are obvious benefits to deployers and users of OpenStack services. While this one is maybe not as immediately obvious, I think this is something that will end up helping deployers and also falls into the tech debt reduction category that will help us move quicker long term. Python 2 is going away soon, so I think we need something to help compel folks to work on making sure we are ready to transition. This will also be a good point to help switch the mindset over to Python 3 being the default used everywhere, with our Python 2 compatibility being just to continue legacy support. Cold Upgrade Support The other suggestion in the Forum session related to upgrades was the addition of "upgrade check" CLIs for each project, and I was tempted to suggest that as my second strawman choice. For some projects that would be a very minimal or NOOP check, so it would probably be easy to complete the goal. But ultimately what I think would bring the most value would be the work on supporting cold upgrade, even if it will be more of a stretch for some projects to accomplish. Upgrades have been a major focus of discussion lately, especially as our operators have been trying to get closer to the latest work upstream. This has been an ongoing challenge. There has also been a lot of talk about LTS releases. We've landed on fast forward upgrade to get between several releases, but I think improving upgrades eases the way both for easier and more frequent upgrades and also getting to the point some day where maybe we can think about upgrading over several releases to be able to do something like an LTS to LTS upgrade. Neither one of these upgrade goals really has a clearly defined plan that projects can pick up now and start working on, but I think with those involved in these areas we should be able to come up with a perscriptive plan for projects to follow. And it would really move our fast forward upgrade story forward. Next Steps == I'm hoping with a strawman proposal we have a basis for debating the merits of these and getting closer to being able to officially select Stein goals. We still have some time, but I would like to avoid making late-cycle selections so teams can start planning ahead for what will need to be done in Stein. Please feel free to promote other ideas for goals. That would be a good way for us to weigh the pro's and con's between these and whatever else you have in mind. Then hopefully we can come to some consensus and work towards clearly defining what needs to be done and getting things well documented for teams to pick up as soon as they wrap up Rocky (or sooner). --- Sean (smcginnis) __ 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
