Open Stack

On Jun 9, 2013, at 10:30 PM, Blair Bethwaite <blair.bethwaite at gmail.com> wrote:

> Hi,
> 
> 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:
> 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
> 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).
> 
> 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?
> 
> 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...
> * 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
> * 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.

I don't see anything immediately wrong with this approach. It was most likely an oversight on my part that flatdchp doesn't respect the project_id setting.

Vish

> 
> 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.
> 
> If I'm not totally of track here I'll file a bug against this and propose a patch.
> 
> Cheers,
> ~Blairo
> 
> [1] More background about why we'd want to do this...
> 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.
> 
> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev