Open Stack

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
[2]
https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#neutron-request-for-feature-enhancements



>
> 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://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/0d36f6f0/attachment.html>