Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA

[Tom Fifield]

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

[Edgar Magana]

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

[Sean M. Collins]

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

[Edgar Magana]

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

[Kris G. Lindgren]

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

[Sean M. Collins]

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]

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

[Sean M. Collins]

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

[Shamail]

> 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
 
 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 

Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA

[Joseph Bajin]

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
>> 

Re: [Openstack-operators] [osops] Finding ways to get operator issues to projects - Starting with NOVA

[Kenny Johnston]

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

[Joseph Bajin]

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

[Joseph Bajin]

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

[Joseph Bajin]

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