Open Stack

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-operators/attachments/20150617/6e38d5f5/attachment.html>