Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes
On 18:04 Nov 06, Doug Hellmann wrote: > One thing I forgot to mention in my original email was the discussion > about when we would have this themes conversation for the N cycle. > I had originally hoped we would discuss the themes online before > the summit, and that those would inform decisions about summit > sessions. Several other folks in the room made the point that we > were unlikely to come up with a theme so surprising that we would > add or drop a summit session from any existing planning, so having > the discussion in person at the summit to add background to the > other sessions for the week was more constructive. I'd like to hear > from some folks about whether that worked out this time, and then > we can decide closer to the N summit whether to use an email thread > or some other venue instead of (or in addition to) a summit session > in Austin. > > I also plan to start some email threads this cycle after each > milestone to re-consider the themes and get feedback about how we're > making progress. I hope the release liaisons, at least, will > participate in those discussions, and it would be great to have the > product working group involved as well. It might make sense to have the cross-project spec liaison [1] to be part of this discussion? [1] - http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html -- Mike Perez __ 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] [all] summarizing the cross-project summit session on Mitaka themes
ent: Monday, November 09, 2015 4:52 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [all] summarizing the cross-project summit > session on Mitaka themes > > Doug Hellmann wrote: > > One thing I forgot to mention in my original email was the discussion > > about when we would have this themes conversation for the N cycle. > > I had originally hoped we would discuss the themes online before the > > summit, and that those would inform decisions about summit sessions. > > Several other folks in the room made the point that we were unlikely > > to come up with a theme so surprising that we would add or drop a > > summit session from any existing planning, so having the discussion in > > person at the summit to add background to the other sessions for the > > week was more constructive. > > So I was stuck in Design Summit 101 during this session and couldn't attend. > Saying that discussing common themes before summit planning is unlikely to > change design summit session contents strikes me as odd. > That's equivalent to saying that the right themes are picked anyway. > That may be the case for some projects, but certainly not the case for all > projects, otherwise we wouldn't be having that discussion to begin with... > > Personally I think we need to have the cycle themes discussion before the > design summit so that it can really influence what gets discussed there and > ends up in real action items. Adding background at the last minute to > already-decided session topics is just not enough to trigger real progress in > those key areas. > > Why can't we have that discussion on the ML in the second half of the cycle, > between the midcycle sprints and the summit planning ? > > -- > 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 > > __ > 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] [all] summarizing the cross-project summit session on Mitaka themes
I'm a bit confused as to the role of Themes today. If they emerge as a result of Project plans, then it seems like documentation, not trying to provide input to set priorities/directions for Projects. Doug: Can you clarify this for me? My interest is to provide input to Project planning, and agree with Thierry,a discussion these ahead of the design summit activities would be valuable to this end. Thanks Carol -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Monday, November 09, 2015 4:52 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes Doug Hellmann wrote: > One thing I forgot to mention in my original email was the discussion > about when we would have this themes conversation for the N cycle. > I had originally hoped we would discuss the themes online before the > summit, and that those would inform decisions about summit sessions. > Several other folks in the room made the point that we were unlikely > to come up with a theme so surprising that we would add or drop a > summit session from any existing planning, so having the discussion in > person at the summit to add background to the other sessions for the > week was more constructive. So I was stuck in Design Summit 101 during this session and couldn't attend. Saying that discussing common themes before summit planning is unlikely to change design summit session contents strikes me as odd. That's equivalent to saying that the right themes are picked anyway. That may be the case for some projects, but certainly not the case for all projects, otherwise we wouldn't be having that discussion to begin with... Personally I think we need to have the cycle themes discussion before the design summit so that it can really influence what gets discussed there and ends up in real action items. Adding background at the last minute to already-decided session topics is just not enough to trigger real progress in those key areas. Why can't we have that discussion on the ML in the second half of the cycle, between the midcycle sprints and the summit planning ? -- 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 __ 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] [all] summarizing the cross-project summit session on Mitaka themes
Doug Hellmann wrote: > One thing I forgot to mention in my original email was the discussion > about when we would have this themes conversation for the N cycle. > I had originally hoped we would discuss the themes online before > the summit, and that those would inform decisions about summit > sessions. Several other folks in the room made the point that we > were unlikely to come up with a theme so surprising that we would > add or drop a summit session from any existing planning, so having > the discussion in person at the summit to add background to the > other sessions for the week was more constructive. So I was stuck in Design Summit 101 during this session and couldn't attend. Saying that discussing common themes before summit planning is unlikely to change design summit session contents strikes me as odd. That's equivalent to saying that the right themes are picked anyway. That may be the case for some projects, but certainly not the case for all projects, otherwise we wouldn't be having that discussion to begin with... Personally I think we need to have the cycle themes discussion before the design summit so that it can really influence what gets discussed there and ends up in real action items. Adding background at the last minute to already-decided session topics is just not enough to trigger real progress in those key areas. Why can't we have that discussion on the ML in the second half of the cycle, between the midcycle sprints and the summit planning ? -- 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] [all] summarizing the cross-project summit session on Mitaka themes
Excerpts from Thierry Carrez's message of 2015-11-09 13:52:11 +0100: > Doug Hellmann wrote: > > One thing I forgot to mention in my original email was the discussion > > about when we would have this themes conversation for the N cycle. > > I had originally hoped we would discuss the themes online before > > the summit, and that those would inform decisions about summit > > sessions. Several other folks in the room made the point that we > > were unlikely to come up with a theme so surprising that we would > > add or drop a summit session from any existing planning, so having > > the discussion in person at the summit to add background to the > > other sessions for the week was more constructive. > > So I was stuck in Design Summit 101 during this session and couldn't > attend. Saying that discussing common themes before summit planning is > unlikely to change design summit session contents strikes me as odd. > That's equivalent to saying that the right themes are picked anyway. > That may be the case for some projects, but certainly not the case for > all projects, otherwise we wouldn't be having that discussion to begin > with... > > Personally I think we need to have the cycle themes discussion before > the design summit so that it can really influence what gets discussed > there and ends up in real action items. Adding background at the last > minute to already-decided session topics is just not enough to trigger > real progress in those key areas. > > Why can't we have that discussion on the ML in the second half of the > cycle, between the midcycle sprints and the summit planning ? > I think their point was that the themes we were coalescing on had already been discussed in different forums, and since most of them were "background" themes (stabilization, functional testing, etc.) that didn't require much discussion to reach agreement they would be unlikely to trigger summit sessions. In the future, that might not be the case, though. I'll be raising the theme issue several times during milestone retrospectives, so we may identify new themes out of those discussions. As we get closer to the end of the cycle, some more explicit time spent brainstorming themes might make sense, too. 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] [all] summarizing the cross-project summit session on Mitaka themes
One thing I forgot to mention in my original email was the discussion about when we would have this themes conversation for the N cycle. I had originally hoped we would discuss the themes online before the summit, and that those would inform decisions about summit sessions. Several other folks in the room made the point that we were unlikely to come up with a theme so surprising that we would add or drop a summit session from any existing planning, so having the discussion in person at the summit to add background to the other sessions for the week was more constructive. I'd like to hear from some folks about whether that worked out this time, and then we can decide closer to the N summit whether to use an email thread or some other venue instead of (or in addition to) a summit session in Austin. I also plan to start some email threads this cycle after each milestone to re-consider the themes and get feedback about how we're making progress. I hope the release liaisons, at least, will participate in those discussions, and it would be great to have the product working group involved as well. As far as rolling upgrades, I know a couple of projects are thinking about that this cycle. As I said in the summary of that part of the session, it's not really a feature that we're going to implement and call "done" so much as a shift in thinking about how we design things in the future. Tracking the specs and blueprints for work related to that across all projects would be helpful, especially early in the cycle like this where feedback on requirements will make the most difference. Doug Excerpts from Barrett, Carol L's message of 2015-11-06 21:32:11 +: > Doug - Thanks for leading the session and this summary. What is your view on > next steps to establish themes for the N-release? And specifically around > rolling upgrades (my personal favorite). > > Thanks > Carol > > -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Friday, November 06, 2015 1:11 PM > To: openstack-dev > Subject: [openstack-dev] [all] summarizing the cross-project summit session > on Mitaka themes > > At the summit last week one of the early cross-project sessions tried to > identify some common “themes” or “goals” for the Mitaka cycle. I proposed the > session to talk about some of the areas of work that all of our teams need to > do, but that fall by the wayside when we don't pull the whole community > together to focus attention on them. We had several ideas proposed, and some > lively discussion about them. The notes are in the etherpad [1], and I will > try to summarize the discussion here. > > 1. Functional testing, especially of client libraries, came up as a result of > a few embarrassingly broken client releases during Liberty. Those issues > were found and fixed quickly, but they exposed a gap in our test coverage. > > 2. Adding tests useful for DefCore and similar interoperability testing was > suggested in part because of our situation in Glance, where many of the > image-related API tests actually talk to the Nova API instead of the Glance > API. We may have other areas where additional tests in tempest could > eventually find their way into the DefCore definition, ensuring more > interoperability between deployed OpenStack clouds. > > 3. We talked for a while about being more opinionated in things like > architecture and deployment dependencies. I don’t think we resolved this one, > but I’m sure the discussion fed into the DLM discussion later that day in a > separate session. > > 4. Improving consistency of quota management across projects came up. We’ve > talked in the past about a separate quota management library or service, but > no one has yet stepped up to spearhead the effort to launch such a project. > > 5. Rolling upgrades was a very popular topic, in the room and on the product > working group’s priority list. The point was made that this requires a shift > in thinking about how to design and implement projects, not just some simple > code changes that can be rolled out in a single cycle. I know many teams are > looking at addressing rolling upgrades. > > 6. os-cloud-config support in clients was raised. There is a cross-project > spec at https://review.openstack.org/#/c/236712/ to cover this. > > 7. "Fixing existing things as a priority over features” came up, and has been > a recurring topic of discussion for a few cycles now. > The idea of having a “maintenance” cycle where all teams was floated, though > it might be tough to get everyone aligned to doing that at the same time. > Alternately, if we work out a way to support individual teams doing that we > could let teams schedule them as they feel they are useful. We could also > d
[openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes
At the summit last week one of the early cross-project sessions tried to identify some common “themes” or “goals” for the Mitaka cycle. I proposed the session to talk about some of the areas of work that all of our teams need to do, but that fall by the wayside when we don't pull the whole community together to focus attention on them. We had several ideas proposed, and some lively discussion about them. The notes are in the etherpad [1], and I will try to summarize the discussion here. 1. Functional testing, especially of client libraries, came up as a result of a few embarrassingly broken client releases during Liberty. Those issues were found and fixed quickly, but they exposed a gap in our test coverage. 2. Adding tests useful for DefCore and similar interoperability testing was suggested in part because of our situation in Glance, where many of the image-related API tests actually talk to the Nova API instead of the Glance API. We may have other areas where additional tests in tempest could eventually find their way into the DefCore definition, ensuring more interoperability between deployed OpenStack clouds. 3. We talked for a while about being more opinionated in things like architecture and deployment dependencies. I don’t think we resolved this one, but I’m sure the discussion fed into the DLM discussion later that day in a separate session. 4. Improving consistency of quota management across projects came up. We’ve talked in the past about a separate quota management library or service, but no one has yet stepped up to spearhead the effort to launch such a project. 5. Rolling upgrades was a very popular topic, in the room and on the product working group’s priority list. The point was made that this requires a shift in thinking about how to design and implement projects, not just some simple code changes that can be rolled out in a single cycle. I know many teams are looking at addressing rolling upgrades. 6. os-cloud-config support in clients was raised. There is a cross-project spec at https://review.openstack.org/#/c/236712/ to cover this. 7. "Fixing existing things as a priority over features” came up, and has been a recurring topic of discussion for a few cycles now. The idea of having a “maintenance” cycle where all teams was floated, though it might be tough to get everyone aligned to doing that at the same time. Alternately, if we work out a way to support individual teams doing that we could let teams schedule them as they feel they are useful. We could also dedicate more review time to maintenance than features, without excluding features entirely. There seemed to be quite a bit of support in the room for the general idea, though making it actionable will take some more thought. 8. Mike Perez is working with teams to increase our third-party CI for vendor-specific drivers and other deployment choices. This theme wouldn’t necessarily apply to every team, but there was a lot of support for it. 9. Training more contributors to debug gate issues came up late in the session. Anita Kuno has taken up this challenge, and has started collecting useful resources in a mailing list thread, the archives for which are split across 2 months, so see both [2] and [3] if you missed it in your email client. 10. We wrapped up with a short discussion of making sure we have all the necessary cross-project liaisons in place to ensure good communication and coordination. Liaisons for Mitaka are listed in https://wiki.openstack.org/wiki/CrossProjectLiaisons [1] https://etherpad.openstack.org/p/mitaka-crossproject-themes [2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077913.html [3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/078173.html __ 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] [all] summarizing the cross-project summit session on Mitaka themes
Doug - Thanks for leading the session and this summary. What is your view on next steps to establish themes for the N-release? And specifically around rolling upgrades (my personal favorite). Thanks Carol -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Friday, November 06, 2015 1:11 PM To: openstack-dev Subject: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes At the summit last week one of the early cross-project sessions tried to identify some common “themes” or “goals” for the Mitaka cycle. I proposed the session to talk about some of the areas of work that all of our teams need to do, but that fall by the wayside when we don't pull the whole community together to focus attention on them. We had several ideas proposed, and some lively discussion about them. The notes are in the etherpad [1], and I will try to summarize the discussion here. 1. Functional testing, especially of client libraries, came up as a result of a few embarrassingly broken client releases during Liberty. Those issues were found and fixed quickly, but they exposed a gap in our test coverage. 2. Adding tests useful for DefCore and similar interoperability testing was suggested in part because of our situation in Glance, where many of the image-related API tests actually talk to the Nova API instead of the Glance API. We may have other areas where additional tests in tempest could eventually find their way into the DefCore definition, ensuring more interoperability between deployed OpenStack clouds. 3. We talked for a while about being more opinionated in things like architecture and deployment dependencies. I don’t think we resolved this one, but I’m sure the discussion fed into the DLM discussion later that day in a separate session. 4. Improving consistency of quota management across projects came up. We’ve talked in the past about a separate quota management library or service, but no one has yet stepped up to spearhead the effort to launch such a project. 5. Rolling upgrades was a very popular topic, in the room and on the product working group’s priority list. The point was made that this requires a shift in thinking about how to design and implement projects, not just some simple code changes that can be rolled out in a single cycle. I know many teams are looking at addressing rolling upgrades. 6. os-cloud-config support in clients was raised. There is a cross-project spec at https://review.openstack.org/#/c/236712/ to cover this. 7. "Fixing existing things as a priority over features” came up, and has been a recurring topic of discussion for a few cycles now. The idea of having a “maintenance” cycle where all teams was floated, though it might be tough to get everyone aligned to doing that at the same time. Alternately, if we work out a way to support individual teams doing that we could let teams schedule them as they feel they are useful. We could also dedicate more review time to maintenance than features, without excluding features entirely. There seemed to be quite a bit of support in the room for the general idea, though making it actionable will take some more thought. 8. Mike Perez is working with teams to increase our third-party CI for vendor-specific drivers and other deployment choices. This theme wouldn’t necessarily apply to every team, but there was a lot of support for it. 9. Training more contributors to debug gate issues came up late in the session. Anita Kuno has taken up this challenge, and has started collecting useful resources in a mailing list thread, the archives for which are split across 2 months, so see both [2] and [3] if you missed it in your email client. 10. We wrapped up with a short discussion of making sure we have all the necessary cross-project liaisons in place to ensure good communication and coordination. Liaisons for Mitaka are listed in https://wiki.openstack.org/wiki/CrossProjectLiaisons [1] https://etherpad.openstack.org/p/mitaka-crossproject-themes [2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077913.html [3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/078173.html __ 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
