Open Stack

Great! I'll reach out to you in unicast mode on this Kris, thanks!

On Wed, Jun 17, 2015 at 10:27 AM, Kris G. Lindgren <klindgren at godaddy.com>
wrote:

>  While I didn't know about the Neutron mid-cycle being next week.  I do
> happen to live in Fort Collins, so I could easy become available if you
> want to talk face-to-face about
> https://bugs.launchpad.net/neutron/+bug/1458890.
>  ____________________________________________
>
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
>
>   From: Kyle Mestery <mestery at mestery.com>
> Date: Wednesday, June 17, 2015 at 7:08 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [openstack-dev] [nova] [neutron] Re:
> How do your end users use networking?
>
>    On Wed, Jun 17, 2015 at 1:59 AM, Armando M. <armamig at gmail.com> wrote:
>
>>
>>
>> On 16 June 2015 at 22:36, Sam Morrison <sorrison at gmail.com> wrote:
>>
>>>
>>>  On 17 Jun 2015, at 10:56 am, Armando M. <armamig at gmail.com> wrote:
>>>
>>>
>>>
>>> On 16 June 2015 at 17:31, Sam Morrison <sorrison at gmail.com> wrote:
>>>
>>>> We at NeCTAR are starting the transition to neutron from nova-net and
>>>> neutron almost does what we want.
>>>>
>>>> We have 10 “public" networks and 10 “service" networks and depending on
>>>> which compute node you land on you get attached to one of them.
>>>>
>>>> In neutron speak we have multiple shared externally routed provider
>>>> networks. We don’t have any tenant networks or any other fancy stuff yet.
>>>> How I’ve currently got this set up is by creating 10 networks and
>>>> subsequent subnets eg. public-1, public-2, public-3 … and service-1,
>>>> service-2, service-3 and so on.
>>>>
>>>> In nova we have made a slight change in allocate for instance [1]
>>>> whereby the compute node has a designated hardcoded network_ids for the
>>>> public and service network it is physically attached to.
>>>> We have also made changes in the nova API so users can’t select a
>>>> network and the neutron endpoint is not registered in keystone.
>>>>
>>>> That all works fine but ideally I want a user to be able to choose if
>>>> they want a public and or service network. We can’t let them as we have 10
>>>> public networks, we almost need something in neutron like a "network group”
>>>> or something that allows a user to select “public” and it allocates them a
>>>> port in one of the underlying public networks.
>>>>
>>>> I tried going down the route of having 1 public and 1 service network
>>>> in neutron then creating 10 subnets under each. That works until you get to
>>>> things like dhcp-agent and metadata agent although this looks like it could
>>>> work with a few minor changes. Basically I need a dhcp-agent to be spun up
>>>> per subnet and ensure they are spun up in the right place.
>>>>
>>>> I’m not sure what the correct way of doing this. What are other people
>>>> doing in the interim until this kind of use case can be done in Neutron?
>>>>
>>>
>>>  Would something like [1] be adequate to address your use case? If not,
>>> I'd suggest you to file an RFE bug (more details in [2]), so that we can
>>> keep the discussion focused on this specific case.
>>>
>>>  HTH
>>> Armando
>>>
>>>  [1] https://blueprints.launchpad.net/neutron/+spec/rbac-networks
>>>
>>>
>>>  That’s not applicable in this case. We don’t care about what tenants
>>> are when in this case.
>>>
>>>    [2]
>>> https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#neutron-request-for-feature-enhancements
>>>
>>>
>>>  The bug Kris mentioned outlines all I want too I think.
>>>
>>
>>  I don't know what you're referring to.
>>
>>
>
>  Armando, I think this is the bug he's referring to:
>
> https://bugs.launchpad.net/neutron/+bug/1458890
>
>  This is something I'd like to look at next week during the mid-cycle,
> especially since Carl is there and his spec for routed networks [2] covers
> a lot of these use cases.
>
> [2] https://review.openstack.org/#/c/172244/
>
>
>>
>>>  Sam
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Sam
>>>>
>>>> [1]
>>>> https://github.com/NeCTAR-RC/nova/commit/1bc2396edc684f83ce471dd9dc9219c4635afb12
>>>>
>>>>
>>>>
>>>> > On 17 Jun 2015, at 12:20 am, Jay Pipes <jaypipes at gmail.com> wrote:
>>>> >
>>>> > Adding -dev because of the reference to the Neutron "Get me a network
>>>> spec". Also adding [nova] and [neutron] subject markers.
>>>> >
>>>> > Comments inline, Kris.
>>>> >
>>>> > On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:
>>>> >> During the Openstack summit this week I got to talk to a number of
>>>> other
>>>> >> operators of large Openstack deployments about how they do
>>>> networking.
>>>> >>  I was happy, surprised even, to find that a number of us are using a
>>>> >> similar type of networking strategy.  That we have similar challenges
>>>> >> around networking and are solving it in our own but very similar way.
>>>> >>  It is always nice to see that other people are doing the same things
>>>> >> as you or see the same issues as you are and that "you are not
>>>> crazy".
>>>> >> So in that vein, I wanted to reach out to the rest of the Ops
>>>> Community
>>>> >> and ask one pretty simple question.
>>>> >>
>>>> >> Would it be accurate to say that most of your end users want almost
>>>> >> nothing to do with the network?
>>>> >
>>>> > That was my experience at AT&T, yes. The vast majority of end users
>>>> could not care less about networking, as long as the connectivity was
>>>> reliable, performed well, and they could connect to the Internet (and have
>>>> others connect from the Internet to their VMs) when needed.
>>>> >
>>>> >> In my experience what the majority of them (both internal and
>>>> external)
>>>> >> want is to consume from Openstack a compute resource, a property of
>>>> >> which is it that resource has an IP address.  They, at most, care
>>>> about
>>>> >> which "network" they are on.  Where a "network" is usually an
>>>> arbitrary
>>>> >> definition around a set of real networks, that are constrained to a
>>>> >> location, in which the company has attached some sort of policy.  For
>>>> >> example, I want to be in the production network vs's the xyz lab
>>>> >> network, vs's the backup network, vs's the corp network.  I would say
>>>> >> for Godaddy, 99% of our use cases would be defined as: I want a
>>>> compute
>>>> >> resource in the production network zone, or I want a compute
>>>> resource in
>>>> >> this other network zone.  The end user only cares that the IP the vm
>>>> >> receives works in that zone, outside of that they don't care any
>>>> other
>>>> >> property of that IP.  They do not care what subnet it is in, what
>>>> vlan
>>>> >> it is on, what switch it is attached to, what router its attached
>>>> to, or
>>>> >> how data flows in/out of that network.  It just needs to work. We
>>>> have
>>>> >> also found that by giving the users a floating ip address that can be
>>>> >> moved between vm's (but still constrained within a "network" zone) we
>>>> >> can solve almost all of our users asks.  Typically, the internal need
>>>> >> for a floating ip is when a compute resource needs to talk to another
>>>> >> protected internal or external resource. Where it is painful (read:
>>>> >> slow) to have the acl's on that protected resource updated. The
>>>> external
>>>> >> need is from our hosting customers who have a domain name (or many)
>>>> tied
>>>> >> to an IP address and changing IP's/DNS is particularly painful.
>>>> >
>>>> > This is precisely my experience as well.
>>>> >
>>>> >> Since the vast majority of our end users don't care about any of the
>>>> >> technical network stuff, we spend a large amount of time/effort in
>>>> >> abstracting or hiding the technical stuff from the users view. Which
>>>> has
>>>> >> lead to a number of patches that we carry on both nova and neutron
>>>> (and
>>>> >> are available on our public github).
>>>> >
>>>> > You may be interested to learn about the "Get Me a Network"
>>>> specification that was discussed in a session at the summit. I had
>>>> requested some time at the summit to discuss this exact use case -- where
>>>> users of Nova actually didn't care much at all about network constructs and
>>>> just wanted to see Nova exhibit similar behaviour as the nova-network
>>>> behaviour of "admin sets up a bunch of unassigned networks and the first
>>>> time a tenant launches a VM, she just gets an available network and
>>>> everything is just done for her".
>>>> >
>>>> > The spec is here:
>>>> >
>>>> > https://review.openstack.org/#/c/184857/
>>>> >
>>>> > > At the same time we also have a
>>>> >> *very* small subset of (internal) users who are at the exact opposite
>>>> >> end of the scale.  They care very much about the network details,
>>>> >> possibly all the way down to that they want to boot a vm to a
>>>> specific
>>>> >> HV, with a specific IP address on a specific network segment.  The
>>>> >> difference however, is that these users are completely aware of the
>>>> >> topology of the network and know which HV's map to which network
>>>> >> segments and are essentially trying to make a very specific ask for
>>>> >> scheduling.
>>>> >
>>>> > Agreed, at Mirantis (and occasionally at AT&T), we do get some
>>>> customers (mostly telcos, of course) that would like total control over all
>>>> things networking.
>>>> >
>>>> > Nothing wrong with this, of course. But the point of the above spec
>>>> is to allow "normal" users to not have to think or know about all the
>>>> advanced networking stuffs if they don't need it. The Neutron API should be
>>>> able to handle both sets of users equally well.
>>>> >
>>>> > Best,
>>>> > -jay
>>>> >
>>>> > _______________________________________________
>>>>  > OpenStack-operators mailing list
>>>> > OpenStack-operators at lists.openstack.org
>>>> >
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> <http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150617/a35da6c7/attachment-0001.html>