Open Stack

Hi all,

This is a problem about the gateway setting in the subnet when one VM could act as a router/firewall. When one VM works
as a router/firewall in the network, the port where the VM connect to the subnet should be the gateway of the subnet.
But now, we can't set the gateway to any VM's port plugged into the subnet because the gateway IP cannot be in the IP allocation pool.

The usage is like this:
1.      Create subnet with a IP allocation pool, specifying the gateway as normal.
2.      Create a router and attach the interfaces with the subnets. With some vendor router-plugin, it will create a router VM and connect this VM with subnets.
   Router VM would get a IP from the pool, but not the gateway IP.
   This the limitation comes, gateway IP could not be allocated to VM, and subnet's gateway could not be updated with IP which has been assigned to some VM.

GatewayConflictWithAllocationPools exception would be emitted.
And this verification code related is https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L1112
It was added by patch for this bug https://bugs.launchpad.net/neutron/+bug/1062061.

Here is an error example:
stack at yalie-Studio-XPS-8000:~/job/dev2/devstack$ neutron subnet-update subnet2  --gateway  10.0.0.3
Gateway ip 10.0.0.3 conflicts with allocation pool 10.0.0.2-10.0.0.254

I think we need to remove this API limitation considering the usage listed, and I want to file a bug about it although I know it may appear be incompatible with the API expected before.
Maybe we could:
1.      Remove this limitation unconditionally. simple but it would conflict with the API behavior before. Is the behavior before bind with something more?
2.      Remove this limitation conditionally. Add a flag for neutron router to delicate whether VM as router or a legacy router. Just rough idea.

More ideas about it?

much appreciate for any comments.

Thanks

/Yalei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150417/49035f4e/attachment.html>