[openstack-dev] [Nova] Why Nova should fail to boot if there are only one private network and one public network ?
Sylvain Bauza
sylvain.bauza at bull.net
Fri Jan 24 14:01:42 UTC 2014
Hi Phil,
Le 24/01/2014 14:13, Day, Phil a écrit :
>
> HI Sylvain,
>
> The change only makes the user have to supply a network ID if there is
> more than one private network available (and the issue there is that
> otherwise the assignment order in the Guest is random, which normally
> leads to all sorts of routing problems).
>
I'm sorry, but the query also includes shared (so, public) networks from
the same tenant. See [1].
> I'm running a standard Devstack with Neuron (built from trunk a couple
> of days ago), can see both a private and public network, and can boot
> VMs without having to supply any network info:
>
>
Indeed, that does work because Devstack is smart enough for creating the
two networks with distinct tenant_ids. See [2] as a proof :-)
If someone is building a private and a public network *on the same
tenant*, it will fail to boot. Apologies if I was unclear.
So, the question is : what shall I do for changing this ? There are 2
options for me:
1. Add an extra param to _get_available_networks : shared=True and
only return shared networks if the param is set to True (so we keep
compatibility with all the calls)
2. Parse the nets dict here [3] to expurge the shared networks when
len(nets) > 1. That's simple but potentially a performance issue, as
it's O(N).
I would personnally vote for #1 and I'm ready to patch. By the way, the
test case needs also to be updated [4].
-Sylvain
[1]
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L127
[2] : http://paste.openstack.org/show/61819/
[3] :
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L528
[4] :
https://github.com/openstack/nova/blob/master/nova/tests/network/test_neutronv2.py#L1028
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/a9b140d2/attachment.html>
More information about the OpenStack-dev
mailing list