[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