Open Stack

[Sorry - unintentionally dropped -operators below; adding it back in 
this copy.]

On 17/06/15 11:35, Neil Jerram 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 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