<div dir="ltr">Hi,<div><br></div><div style>We tried to add a private project specific fixed network [1] to a Folsom install running in FlatDHCP multihost with a single _public_ fixed range per _cell_. nova-manage command like so:</div>









<div style>nova-manage network create --fixed_range_v4=172.16.x.0/24 --num_networks=1 --network_size=256 --label=integration-test --multi_host=T --bridge=brXXX --bridge_interface=bond0.XXX --project=d57d...78</div><div style>

Things looked good at the outset, our new instances were getting two IPs, one from the existing public fixed range and another from our new private range... but then we realised all projects were getting two networks! Not what we thought would happen when we created the network specifying a project_id, and none of the docs say otherwise (but they don't really say anything about this sort of thing).</div>

<div style><br></div><div style>What we think we've discovered after a bit more digging is that the network-project association is only currently applicable to VlanManager - can anybody confirm?</div><div style><br></div>

<div style>Looking at the code I think there may be a simple fix to support our case. Now I'm not even confident I've found the relevant code, but here goes anyway...</div><div style>* nova/network/manager.py:NetworkManager._get_networks_for_instance calls db.network_get_all if there are no networks specifically requested, which is the case we're dealing with I think</div>

<div style>* network_get_all does a simple select all query on the networks table only filtering out deleted, so it literally returns all networks in the table (here's the problem). I think perhaps the query should also be specifying project_only='allow_none', IIUC that would then match entries in the networks table with both project=NULL/None or a specific project.</div>

<div style><br></div><div style>I can't see any other code relying on network_get_all which would be adversely affected, but it is used by an api method.</div><div style><br></div><div style>If I'm not totally of track here I'll file a bug against this and propose a patch.</div>

<div><br></div><div style>Cheers,</div><div style>~Blairo</div><div><br></div><div style>[1] More background about why we'd want to do this...</div><div>We're part of a public cloud currently on Folsom running in FlatDHCP multihost with a single _public_ fixed range per _cell_. That's working well, however our users are struggling trying to hook into existing local services (NFS shared storage is typical example) - due to the ephemeral nature of the fixed ips they can't have dynamically scalable services dependent on an NFS server because they need to know their IP ranges to open exports etc.</div>

<div><br></div><div>Because of this we thought we could add new private fixed range networks to cater to the tenants requiring that kind of integration. The docs seem to suggest this is possible - you can specify project_id when creating a network and that network has that project_id assigned in the database. We assumed this would result in multinic setting up two interfaces for new instances belonging to that/those project/s associated with that/those networks.<br>

<div><div><br></div></div></div></div>