Open Stack

> On 17 Jun 2015, at 8:35 pm, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> 
> Hi Sam,
> 
> On 17/06/15 01:31, Sam Morrison 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.
> 
> This begs the question: why have you defined 10 public-N networks, instead of just one "public" network?

I think this has all been answered but just in case.
There are multiple reasons. We don’t have a single IPv4 range big enough for our cloud, don’t want the broadcast domain too be massive, the compute nodes are in different data centres etc. etc.
Basically it’s not how our underlying physical network is set up and we can’t change that.

Sam


> 
>> 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.
> 
> Why the 10 subnets?  Is it to do with where you actually have real L2 segments, in your deployment?
> 
> Thanks,
> 	Neil
> 
> __________________________________________________________________________
> 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