[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-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
