Open Stack

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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130610/e34ce66d/attachment.html>