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 <klindg...@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 <mest...@mestery.com> > Date: Wednesday, June 17, 2015 at 7:08 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Cc: "openstack-operat...@lists.openstack.org" < > openstack-operat...@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. <arma...@gmail.com> wrote: > >> >> >> On 16 June 2015 at 22:36, Sam Morrison <sorri...@gmail.com> wrote: >> >>> >>> On 17 Jun 2015, at 10:56 am, Armando M. <arma...@gmail.com> wrote: >>> >>> >>> >>> On 16 June 2015 at 17:31, Sam Morrison <sorri...@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 <jaypi...@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-operat...@lists.openstack.org >>>> > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev