[openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Armando M. armamig at gmail.com
Wed Jun 17 06:59:02 UTC 2015


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.


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/fad3542c/attachment.html>


More information about the OpenStack-dev mailing list