Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
On 12/04/16 22:12, Clayton O'Neill wrote: On Tue, Apr 12, 2016 at 9:09 AM, Sean M. Collins wrote: Joseph Bajin wrote: Maybe I'm wrong about this, maybe all the entries from the etherpads are read by projects and fed into their pipelines. They might, but they also might not. There are more etherpads created than there is human capacity to process. Same thing with bugs and RFEs. Just making them isn't sufficient. My point is: Kris had success, I believe, because they went to the Neutron midcycle and participated directly in the development process. Neutron developers were informed of their need, consensus was built, and the work got done. This sort of story is exactly why I think we should have the Ops Mid-Cycle colocated with the new Design Summit replacement. I agree with you that it’s likely the most of the information that’s gathered in the ether pads isn’t looked at, or isn’t in actionable form. As an operator it’s hard for me to justify nearly a month of travel for two summits a year, two Ops mid-cycles a year *and* the Design Summit replacements twice a year. Hi Clayton, Please allow me to clarify some things, because this opinion might be based on a misconception regarding the proposed event split :) The developer-centric event is designed to provide a place where developers can be neck-deep in python code, working on the technical "how" of implementation without interruption. Unless you're an active coder, working on the code base of a particular project, it's not the place to participate in the development process. Today, the "what" and "why" discussions of the development process that the majority of ops can more actively participate in are happening at the individual project mid-cycles. This is what Kris participated in. However, due to the proposed event split's release cycle changes these discussions will move to the summit. Regards, Tom ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
This is a very good input. Just to clarify on the bug & bp reports. Yes, during the Ops meetups we encourage people to file them and provide as much as possible details on the issue or feature request. In some cases we even file them together to make sure that new operators understand the whole process. I also have to agree with Sean than there are a lot of good information in a unlimited number of ether pads that is impossible to analyze. So, there you have your startup idea: Have an analytics app that extracts useful details out of a bunch of etherpads. :-).. Edgar On 4/12/16, 7:12 AM, "Clayton O'Neill" wrote: >On Tue, Apr 12, 2016 at 9:09 AM, Sean M. Collins wrote: >> Joseph Bajin wrote: >>> Maybe I'm wrong about this, maybe all the entries from the etherpads are >>> read by projects and fed into their pipelines. >> >> They might, but they also might not. There are more etherpads created >> than there is human capacity to process. Same thing with bugs and RFEs. >> Just making them isn't sufficient. >> >> My point is: Kris had success, I believe, because they went to the >> Neutron midcycle and participated directly in the development process. >> Neutron developers were informed of their need, consensus was built, and >> the work got done. > >This sort of story is exactly why I think we should have the Ops >Mid-Cycle colocated with the new Design Summit replacement. I agree >with you that it’s likely the most of the information that’s gathered >in the ether pads isn’t looked at, or isn’t in actionable form. As an >operator it’s hard for me to justify nearly a month of travel for two >summits a year, two Ops mid-cycles a year *and* the Design Summit >replacements twice a year. > >___ >OpenStack-operators mailing list >OpenStack-operators@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
On Tue, Apr 12, 2016 at 9:09 AM, Sean M. Collins wrote: > Joseph Bajin wrote: >> Maybe I'm wrong about this, maybe all the entries from the etherpads are >> read by projects and fed into their pipelines. > > They might, but they also might not. There are more etherpads created > than there is human capacity to process. Same thing with bugs and RFEs. > Just making them isn't sufficient. > > My point is: Kris had success, I believe, because they went to the > Neutron midcycle and participated directly in the development process. > Neutron developers were informed of their need, consensus was built, and > the work got done. This sort of story is exactly why I think we should have the Ops Mid-Cycle colocated with the new Design Summit replacement. I agree with you that it’s likely the most of the information that’s gathered in the ether pads isn’t looked at, or isn’t in actionable form. As an operator it’s hard for me to justify nearly a month of travel for two summits a year, two Ops mid-cycles a year *and* the Design Summit replacements twice a year. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Joseph Bajin wrote: > Maybe I'm wrong about this, maybe all the entries from the etherpads are > read by projects and fed into their pipelines. They might, but they also might not. There are more etherpads created than there is human capacity to process. Same thing with bugs and RFEs. Just making them isn't sufficient. My point is: Kris had success, I believe, because they went to the Neutron midcycle and participated directly in the development process. Neutron developers were informed of their need, consensus was built, and the work got done. "Throwing it over the wall" in the form of user stories, working groups, and other things is not enough. Unless we have operators active in the developer community, pushing things the way Kris' organization did, things will just stay as they are. I have experience with this. When the organization I was part of *needed* IPv6 to work, we had to form a team of developers from interested organizations, within the Neutron community, to get things done. Writing a user story and just waiting for it to "happen" probably won't work. > That last point is what I am looking to help change. There is a lot that I > think the group can help out with to make sure we capture what we get via > etherpads and turn them into "Blueprints", "Bugs", etc so we can help > follow-up with projects and track them for the entire Operators group. I think this is a great idea. -- Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Sean, I think this is exactly what I think we are looking to change. There is a lot of work that is captured via etherpad's at each of the Midcycle and other meetups that is probably not sent up to each of the groups. The reason I think this is because I see the some of the same issues that Operators are discussing over and over again. Now, there is work that Kris mentioned that they have submitted and keep on top of, and I know there is other work from a few others that contribute, but I'm not sure if the rest of the Operators have the opportunity to get their information over to the right people. That last point is what I am looking to help change. There is a lot that I think the group can help out with to make sure we capture what we get via etherpads and turn them into "Blueprints", "Bugs", etc so we can help follow-up with projects and track them for the entire Operators group. Maybe I'm wrong about this, maybe all the entries from the etherpads are read by projects and fed into their pipelines. --Joe On Mon, Apr 11, 2016 at 11:11 AM, Sean M. Collins wrote: > To be blunt: Are we ensuring that all this work that people are > capturing in these working groups is actually getting updated and > communicated to the developers? > > As I become more involved with rolling upgrades, I will try and attend > meetings and be available from the WG side, but I don't believe I've > ever seen someone from the WG side come over to Neutron and say "We need > XYZ and here's a link to what we've captured in our repo to explain what > we mean" > > But then again I'm not on the neutron-drivers team or a core. > > Anyway, I updated what I've been involved with in the Mitaka cycle, when > it comes to Neutron and upgrades (https://review.openstack.org/304181) > > -- > Sean M. Collins > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Sean, This is a very good concern. I can't talk for all projects but during the Ops Meet-ups we normally collect the feedback and send it to the PTLs or anyone from the project team who can help us. The best answer should be provide by the Product Working Group from User Committee: https://wiki.openstack.org/wiki/ProductTeam Adding Shamail and Carol to provide more details. They are leading the Product WG. Thanks, Edgar On 4/11/16, 8:58 AM, "Sean M. Collins" wrote: >Kris G. Lindgren wrote: >> You mean outside of the LDT filing an RFE bug with neutron to get > >Sorry, I don't know what LDT is. Can you explain? > >As for the RFE bug and the contributions that GoDaddy has been involved >with, my statement is not about "if" operators are contributing, because >obviously they are. But an RFE bug and coming to the midcycle is part of >Neutron's development process. Not a working group. > > >-- >Sean M. Collins > >___ >OpenStack-operators mailing list >OpenStack-operators@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
LDT is large deployment team, its a working group for large deployments. Like Rackspace, Cern, NeCTAR, Yahoo, GoDaddy, Bluebox. Talk about issues scaling openstack, Nova cells, monitoring, all the stuff that becomes hard when you have thousands of servers or hundreds of clouds. Also, the public-cloud working group is part of the LDT working group as well. Since a large portion of us also happen to run public clouds. Sorry - but your post came off (to me) as: Working groups don’t do anything actionable, atleast I have never seen it in neutron. I was just giving actionable work that has come from LDT, alone, in neutron. ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy On 4/11/16, 9:58 AM, "Sean M. Collins" wrote: >Kris G. Lindgren wrote: >> You mean outside of the LDT filing an RFE bug with neutron to get > >Sorry, I don't know what LDT is. Can you explain? > >As for the RFE bug and the contributions that GoDaddy has been involved >with, my statement is not about "if" operators are contributing, because >obviously they are. But an RFE bug and coming to the midcycle is part of >Neutron's development process. Not a working group. > > >-- >Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Kris G. Lindgren wrote: > You mean outside of the LDT filing an RFE bug with neutron to get Sorry, I don't know what LDT is. Can you explain? As for the RFE bug and the contributions that GoDaddy has been involved with, my statement is not about "if" operators are contributing, because obviously they are. But an RFE bug and coming to the midcycle is part of Neutron's development process. Not a working group. -- Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
You mean outside of the LDT filing an RFE bug with neutron to get segmented/routed network support added to neutron complete with an etherpad of all the ways we are using that at our companies and our use cases [1] . Or where we (GoDaddy) came to the neutron Mid-cycle in Fort Collins to further talk about said use case as well as to put feelers out for ip-usages-extension. Which was commited to Neutron in the Mitaka release [2]. These are just the things that I was am aware of and have been involved in neutron alone in the past 6 months, I am sure there are many more. [1] - https://etherpad.openstack.org/p/Network_Segmentation_Usecases & https://bugs.launchpad.net/neutron/+bug/1458890 [2] - https://github.com/openstack/neutron/commit/2f741ca5f9545c388270ddab774e9e030b006d8a ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy On 4/11/16, 9:11 AM, "Sean M. Collins" wrote: >To be blunt: Are we ensuring that all this work that people are >capturing in these working groups is actually getting updated and >communicated to the developers? > >As I become more involved with rolling upgrades, I will try and attend >meetings and be available from the WG side, but I don't believe I've >ever seen someone from the WG side come over to Neutron and say "We need >XYZ and here's a link to what we've captured in our repo to explain what >we mean" > >But then again I'm not on the neutron-drivers team or a core. > >Anyway, I updated what I've been involved with in the Mitaka cycle, when >it comes to Neutron and upgrades (https://review.openstack.org/304181) > >-- >Sean M. Collins > >___ >OpenStack-operators mailing list >OpenStack-operators@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
To be blunt: Are we ensuring that all this work that people are capturing in these working groups is actually getting updated and communicated to the developers? As I become more involved with rolling upgrades, I will try and attend meetings and be available from the WG side, but I don't believe I've ever seen someone from the WG side come over to Neutron and say "We need XYZ and here's a link to what we've captured in our repo to explain what we mean" But then again I'm not on the neutron-drivers team or a core. Anyway, I updated what I've been involved with in the Mitaka cycle, when it comes to Neutron and upgrades (https://review.openstack.org/304181) -- Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
> On Apr 7, 2016, at 9:23 PM, Edgar Magana wrote: > > Hello, > > I do agree that PWG should be the place for collecting product features > requirements and properly delivered to the project teams. I am not sure how > to use OSOps for User Stories, any example of that? The Enterprise WG and Telco WG are already submitting their user stories into the Product WG and we would be glad to welcome user stories from the Ops community as well! One way to use OSOps might be to copy the template[1] from the product working group and collaborate with other operators to refine the user story, however I would still encourage eventual submission to the product working group repository. This would help us ensure that user stories from multiple sources are available in a common area. If you would like to learn more about the Product Working Group then the birds of a feather session[2] at the summit will be a great one to join! I echo what Kenny said, we would love user stories from OpenStack operators! [1] https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst [2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9041 > > Edgar > > From: Joseph Bajin > Date: Wednesday, April 6, 2016 at 5:50 AM > To: Kenny Johnston > Cc: OpenStack Operators > Subject: Re: [Openstack-operators] [osops] Finding ways to get operator > issues to projects - Starting with NOVA > > This is great Kenny! > > I will see about attending one of the PWG sessions in the next few weeks. > > What I was thinking and maybe this works or doesn't was to have the "OSOps" > group be that central point where Operators could feed User Stories. I was > thinking that this may make it easier for groups to see all the Operators > requests, User Stories, complaints, appreciations, etc in one central > location. That way if someone didn't know that there was say Product Work > Group, they at least could get their story down for others to see. > > > >> On Tue, Apr 5, 2016 at 2:25 PM, Kenny Johnston >> wrote: >> I'll throw this out there but the Product Work Group[1] has a place for >> submitting "User Stories"[2] which are meant to be robust descriptions of >> problem statements and use cases. Speaking as a core PWG team member, I can >> say we'd love to have operators submit User Stories with whatever level of >> detail they have available so our Product Team can help iterate and flesh >> out the stories for consideration by project teams. >> >> You can find the PWG team in #openstack-product or in the PWG Mailling >> list[3] >> >> [1]https://wiki.openstack.org/wiki/ProductTeam >> [2]https://github.com/openstack/openstack-user-stories >> [3]http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg >> >>> On Tue, Apr 5, 2016 at 12:29 PM, Joseph Bajin wrote: >>> Hi Christoph, >>> >>> This is a great idea and a tool I think others would be very interested in >>> having. >>> >>> Now the question that I have to you and everyone else, is within the >>> Operators community how would we capture this information so we could open >>> up dialogue with both the Neutron and Nova teams? >>> >>> --Joe >>> >>>> On Tue, Mar 29, 2016 at 11:43 AM, Christoph Andreas Torlinsky >>>> wrote: >>>> Hi Joseph, we would propose a migration tool for getting the NOVA >>>> networking database information into mapping it Neutron, >>>> as we are seeing an increasing demand to "upgrade" from Nova Networking to >>>> an OpenStack Neutron and SDN 3rd Party based >>>> model for Cloud Computing amongst our installed base of OpenStack >>>> customers, some of whom grew out of Nova networking and it's >>>> limits in leveraging VLANs. >>>> >>>> I also caught sight of the recent write ups here , which seem to point in >>>> the same direction actually, in lieu of adoption of Liberty from >>>> older release: >>>> >>>> http://docs.openstack.org/liberty/networking-guide/migration-nova-network-to-neutron.html >>>> >>>> Any tooling to make this easier as a migration process, we (me) are keen >>>> to engage and help, >>>> >>>> Let us know if anyone else is on the same level working on things, >>>> >>>> c >>>> >>>> >>>> Christoph Andreas Torlinski >>>> +44(0)7872413856 UK Mobile >>>> christ...@nuagenetworks.net >>
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Hello, I do agree that PWG should be the place for collecting product features requirements and properly delivered to the project teams. I am not sure how to use OSOps for User Stories, any example of that? Edgar From: Joseph Bajin mailto:josephba...@gmail.com>> Date: Wednesday, April 6, 2016 at 5:50 AM To: Kenny Johnston mailto:ke...@kencjohnston.com>> Cc: OpenStack Operators mailto:openstack-operators@lists.openstack.org>> Subject: Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA This is great Kenny! I will see about attending one of the PWG sessions in the next few weeks. What I was thinking and maybe this works or doesn't was to have the "OSOps" group be that central point where Operators could feed User Stories. I was thinking that this may make it easier for groups to see all the Operators requests, User Stories, complaints, appreciations, etc in one central location. That way if someone didn't know that there was say Product Work Group, they at least could get their story down for others to see. On Tue, Apr 5, 2016 at 2:25 PM, Kenny Johnston mailto:ke...@kencjohnston.com>> wrote: I'll throw this out there but the Product Work Group[1] has a place for submitting "User Stories"[2] which are meant to be robust descriptions of problem statements and use cases. Speaking as a core PWG team member, I can say we'd love to have operators submit User Stories with whatever level of detail they have available so our Product Team can help iterate and flesh out the stories for consideration by project teams. You can find the PWG team in #openstack-product or in the PWG Mailling list[3] [1]https://wiki.openstack.org/wiki/ProductTeam [2]https://github.com/openstack/openstack-user-stories [3]http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg On Tue, Apr 5, 2016 at 12:29 PM, Joseph Bajin mailto:josephba...@gmail.com>> wrote: Hi Christoph, This is a great idea and a tool I think others would be very interested in having. Now the question that I have to you and everyone else, is within the Operators community how would we capture this information so we could open up dialogue with both the Neutron and Nova teams? --Joe On Tue, Mar 29, 2016 at 11:43 AM, Christoph Andreas Torlinsky mailto:christ...@nuagenetworks.net>> wrote: Hi Joseph, we would propose a migration tool for getting the NOVA networking database information into mapping it Neutron, as we are seeing an increasing demand to "upgrade" from Nova Networking to an OpenStack Neutron and SDN 3rd Party based model for Cloud Computing amongst our installed base of OpenStack customers, some of whom grew out of Nova networking and it's limits in leveraging VLANs. I also caught sight of the recent write ups here , which seem to point in the same direction actually, in lieu of adoption of Liberty from older release: http://docs.openstack.org/liberty/networking-guide/migration-nova-network-to-neutron.html Any tooling to make this easier as a migration process, we (me) are keen to engage and help, Let us know if anyone else is on the same level working on things, c [https://assets.sdncentral.com/13790292840.07477300.] Christoph Andreas Torlinski +44(0)7872413856 UK Mobile christ...@nuagenetworks.net<mailto:christ...@nuagenetworks.net> On 26 March 2016 at 20:47, Joseph Bajin mailto:josephba...@gmail.com>> wrote: Operators, At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova Team) talk with us about a proposal that they are working on. The Nova team would like to abandon the use of a wish-list as it has grown to an unmanageable size. They have posted a few times to both the operators list [1] as well as the developers list [2] about their idea. They would like to work with us operators to find the best way to get our ideas into their prioritization list. At the mid-cycle and summit meet-ups, we continue to create etherpads [3] that make mention to the troubles we have, as well as the work we have done to overcome them. These are examples of the work that the NOVA team would like to hear about. I'd like to gather some ideas and thoughts from the operator community on not only the NOVA proposal but ways that we could get the feedback we create each cycle to each of the respective projects. One idea that I have is using the OSOps repo as a way for us to gather and track these wishlist type of items. Then the OSOps working group could be used to help try get these worked on. I'd love to get help and hear ideas from others about how we could improve and build on this process. Please let me know your thoughts. Thanks Joe [1] http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html [2] http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html [3] https://etherpad.ope
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
This is great Kenny! I will see about attending one of the PWG sessions in the next few weeks. What I was thinking and maybe this works or doesn't was to have the "OSOps" group be that central point where Operators could feed User Stories. I was thinking that this may make it easier for groups to see all the Operators requests, User Stories, complaints, appreciations, etc in one central location. That way if someone didn't know that there was say Product Work Group, they at least could get their story down for others to see. On Tue, Apr 5, 2016 at 2:25 PM, Kenny Johnston wrote: > I'll throw this out there but the Product Work Group[1] has a place for > submitting "User Stories"[2] which are meant to be robust descriptions of > problem statements and use cases. Speaking as a core PWG team member, I can > say we'd love to have operators submit User Stories with whatever level of > detail they have available so our Product Team can help iterate and flesh > out the stories for consideration by project teams. > > You can find the PWG team in #openstack-product or in the PWG Mailling > list[3] > > [1]https://wiki.openstack.org/wiki/ProductTeam > [2]https://github.com/openstack/openstack-user-stories > [3]http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg > > On Tue, Apr 5, 2016 at 12:29 PM, Joseph Bajin > wrote: > >> Hi Christoph, >> >> This is a great idea and a tool I think others would be very interested >> in having. >> >> Now the question that I have to you and everyone else, is within the >> Operators community how would we capture this information so we could open >> up dialogue with both the Neutron and Nova teams? >> >> --Joe >> >> On Tue, Mar 29, 2016 at 11:43 AM, Christoph Andreas Torlinsky < >> christ...@nuagenetworks.net> wrote: >> >>> Hi Joseph, we would propose a migration tool for getting the NOVA >>> networking database information into mapping it Neutron, >>> as we are seeing an increasing demand to "upgrade" from Nova Networking >>> to an OpenStack Neutron and SDN 3rd Party based >>> model for Cloud Computing amongst our installed base of OpenStack >>> customers, some of whom grew out of Nova networking and it's >>> limits in leveraging VLANs. >>> >>> I also caught sight of the recent write ups here , which seem to point >>> in the same direction actually, in lieu of adoption of Liberty from >>> older release: >>> >>> >>> http://docs.openstack.org/liberty/networking-guide/migration-nova-network-to-neutron.html >>> >>> Any tooling to make this easier as a migration process, we (me) are keen >>> to engage and help, >>> >>> Let us know if anyone else is on the same level working on things, >>> >>> c >>> >>> >>> Christoph Andreas Torlinski >>> >>> +44(0)7872413856 UK Mobile >>> >>> christ...@nuagenetworks.net >>> >>> On 26 March 2016 at 20:47, Joseph Bajin wrote: >>> Operators, At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova Team) talk with us about a proposal that they are working on. The Nova team would like to abandon the use of a wish-list as it has grown to an unmanageable size. They have posted a few times to both the operators list [1] as well as the developers list [2] about their idea. They would like to work with us operators to find the best way to get our ideas into their prioritization list. At the mid-cycle and summit meet-ups, we continue to create etherpads [3] that make mention to the troubles we have, as well as the work we have done to overcome them. These are examples of the work that the NOVA team would like to hear about. I'd like to gather some ideas and thoughts from the operator community on not only the NOVA proposal but ways that we could get the feedback we create each cycle to each of the respective projects. One idea that I have is using the OSOps repo as a way for us to gather and track these wishlist type of items. Then the OSOps working group could be used to help try get these worked on. I'd love to get help and hear ideas from others about how we could improve and build on this process. Please let me know your thoughts. Thanks Joe [1] http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html [2] http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html [3] https://etherpad.openstack.org/p/operator-local-patches ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > > -- > Kenny Johnston | irc:kencjohnston | @kencjohnston >
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
I'll throw this out there but the Product Work Group[1] has a place for submitting "User Stories"[2] which are meant to be robust descriptions of problem statements and use cases. Speaking as a core PWG team member, I can say we'd love to have operators submit User Stories with whatever level of detail they have available so our Product Team can help iterate and flesh out the stories for consideration by project teams. You can find the PWG team in #openstack-product or in the PWG Mailling list[3] [1]https://wiki.openstack.org/wiki/ProductTeam [2]https://github.com/openstack/openstack-user-stories [3]http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg On Tue, Apr 5, 2016 at 12:29 PM, Joseph Bajin wrote: > Hi Christoph, > > This is a great idea and a tool I think others would be very interested in > having. > > Now the question that I have to you and everyone else, is within the > Operators community how would we capture this information so we could open > up dialogue with both the Neutron and Nova teams? > > --Joe > > On Tue, Mar 29, 2016 at 11:43 AM, Christoph Andreas Torlinsky < > christ...@nuagenetworks.net> wrote: > >> Hi Joseph, we would propose a migration tool for getting the NOVA >> networking database information into mapping it Neutron, >> as we are seeing an increasing demand to "upgrade" from Nova Networking >> to an OpenStack Neutron and SDN 3rd Party based >> model for Cloud Computing amongst our installed base of OpenStack >> customers, some of whom grew out of Nova networking and it's >> limits in leveraging VLANs. >> >> I also caught sight of the recent write ups here , which seem to point in >> the same direction actually, in lieu of adoption of Liberty from >> older release: >> >> >> http://docs.openstack.org/liberty/networking-guide/migration-nova-network-to-neutron.html >> >> Any tooling to make this easier as a migration process, we (me) are keen >> to engage and help, >> >> Let us know if anyone else is on the same level working on things, >> >> c >> >> >> Christoph Andreas Torlinski >> >> +44(0)7872413856 UK Mobile >> >> christ...@nuagenetworks.net >> >> On 26 March 2016 at 20:47, Joseph Bajin wrote: >> >>> Operators, >>> >>> At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova >>> Team) talk with us about a proposal that they are working on. The Nova team >>> would like to abandon the use of a wish-list as it has grown to an >>> unmanageable size. They have posted a few times to both the operators list >>> [1] as well as the developers list [2] about their idea. They would like >>> to work with us operators to find the best way to get our ideas into their >>> prioritization list. At the mid-cycle and summit meet-ups, we continue to >>> create etherpads [3] that make mention to the troubles we have, as well as >>> the work we have done to overcome them. These are examples of the work that >>> the NOVA team would like to hear about. >>> >>> I'd like to gather some ideas and thoughts from the operator community >>> on not only the NOVA proposal but ways that we could get the feedback we >>> create each cycle to each of the respective projects. One idea that I have >>> is using the OSOps repo as a way for us to gather and track these wishlist >>> type of items. Then the OSOps working group could be used to help try get >>> these worked on. >>> >>> I'd love to get help and hear ideas from others about how we could >>> improve and build on this process. Please let me know your thoughts. >>> >>> Thanks >>> >>> Joe >>> >>> >>> [1] >>> http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html >>> [2] >>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html >>> [3] https://etherpad.openstack.org/p/operator-local-patches >>> >>> >>> ___ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> >> > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Kenny Johnston | irc:kencjohnston | @kencjohnston ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Hi Christoph, This is a great idea and a tool I think others would be very interested in having. Now the question that I have to you and everyone else, is within the Operators community how would we capture this information so we could open up dialogue with both the Neutron and Nova teams? --Joe On Tue, Mar 29, 2016 at 11:43 AM, Christoph Andreas Torlinsky < christ...@nuagenetworks.net> wrote: > Hi Joseph, we would propose a migration tool for getting the NOVA > networking database information into mapping it Neutron, > as we are seeing an increasing demand to "upgrade" from Nova Networking to > an OpenStack Neutron and SDN 3rd Party based > model for Cloud Computing amongst our installed base of OpenStack > customers, some of whom grew out of Nova networking and it's > limits in leveraging VLANs. > > I also caught sight of the recent write ups here , which seem to point in > the same direction actually, in lieu of adoption of Liberty from > older release: > > > http://docs.openstack.org/liberty/networking-guide/migration-nova-network-to-neutron.html > > Any tooling to make this easier as a migration process, we (me) are keen > to engage and help, > > Let us know if anyone else is on the same level working on things, > > c > > > Christoph Andreas Torlinski > > +44(0)7872413856 UK Mobile > > christ...@nuagenetworks.net > > On 26 March 2016 at 20:47, Joseph Bajin wrote: > >> Operators, >> >> At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova >> Team) talk with us about a proposal that they are working on. The Nova team >> would like to abandon the use of a wish-list as it has grown to an >> unmanageable size. They have posted a few times to both the operators list >> [1] as well as the developers list [2] about their idea. They would like >> to work with us operators to find the best way to get our ideas into their >> prioritization list. At the mid-cycle and summit meet-ups, we continue to >> create etherpads [3] that make mention to the troubles we have, as well as >> the work we have done to overcome them. These are examples of the work that >> the NOVA team would like to hear about. >> >> I'd like to gather some ideas and thoughts from the operator community on >> not only the NOVA proposal but ways that we could get the feedback we >> create each cycle to each of the respective projects. One idea that I have >> is using the OSOps repo as a way for us to gather and track these wishlist >> type of items. Then the OSOps working group could be used to help try get >> these worked on. >> >> I'd love to get help and hear ideas from others about how we could >> improve and build on this process. Please let me know your thoughts. >> >> Thanks >> >> Joe >> >> >> [1] >> http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html >> [2] >> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html >> [3] https://etherpad.openstack.org/p/operator-local-patches >> >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Just sending this out to the Operator Community for more feedback. We'll be having a session at the summit about it, but I'd like to get this discussion going a little more here if we could. --Joe On Sat, Mar 26, 2016 at 4:47 PM, Joseph Bajin wrote: > Operators, > > At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova Team) > talk with us about a proposal that they are working on. The Nova team would > like to abandon the use of a wish-list as it has grown to an unmanageable > size. They have posted a few times to both the operators list [1] as well > as the developers list [2] about their idea. They would like to work with > us operators to find the best way to get our ideas into their > prioritization list. At the mid-cycle and summit meet-ups, we continue to > create etherpads [3] that make mention to the troubles we have, as well as > the work we have done to overcome them. These are examples of the work that > the NOVA team would like to hear about. > > I'd like to gather some ideas and thoughts from the operator community on > not only the NOVA proposal but ways that we could get the feedback we > create each cycle to each of the respective projects. One idea that I have > is using the OSOps repo as a way for us to gather and track these wishlist > type of items. Then the OSOps working group could be used to help try get > these worked on. > > I'd love to get help and hear ideas from others about how we could improve > and build on this process. Please let me know your thoughts. > > Thanks > > Joe > > > [1] > http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html > [2] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html > [3] https://etherpad.openstack.org/p/operator-local-patches > > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA
Operators, At the last OSOps Tools and Monitoring meeting, we had mriedem (Nova Team) talk with us about a proposal that they are working on. The Nova team would like to abandon the use of a wish-list as it has grown to an unmanageable size. They have posted a few times to both the operators list [1] as well as the developers list [2] about their idea. They would like to work with us operators to find the best way to get our ideas into their prioritization list. At the mid-cycle and summit meet-ups, we continue to create etherpads [3] that make mention to the troubles we have, as well as the work we have done to overcome them. These are examples of the work that the NOVA team would like to hear about. I'd like to gather some ideas and thoughts from the operator community on not only the NOVA proposal but ways that we could get the feedback we create each cycle to each of the respective projects. One idea that I have is using the OSOps repo as a way for us to gather and track these wishlist type of items. Then the OSOps working group could be used to help try get these worked on. I'd love to get help and hear ideas from others about how we could improve and build on this process. Please let me know your thoughts. Thanks Joe [1] http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html [2] http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html [3] https://etherpad.openstack.org/p/operator-local-patches ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators