--no-gateway results in dnsmasq using dhcpserver ip as default gw

My initial approach using did not work as expected. I changed approaches and took a second look at passing this as part of the dhcp options. I've refined the way that options are serialized to file to address this issue.

Fix proposed to branch: master
Review: https://review.openstack.org/12394

This patch looks like a good fix for the issue described above, but I'm concerned we have a more general issue around the implementation not being consistent with what we at least originally envisioned for the spec (see host_routes attribute of a subnet: http://wiki.openstack.org/QuantumV2APIIntro).

At issue are scenarios where a subnet has a gateway, but this gateway is not the default gateway. This about a scenario where all VMs have two NICs. The first NIC is plugged into network public, which has a gateway IP of 9.9.9.1, and acts as the default gateway for VM traffic. The second VM NIC is plugging into network private, which is specific to the tenant. This network has a gateway IP as well of 17.16.20.1. This gateway IP is not the default gateway for VMs (otherwise the VMs would get two default gateways), it is simply a gateway that provides access to the a particular IP prefix (e.g., 172.16.19.0/24). For example, this might be a remote network in the customer premises.

The original design for host_routes handled this by saying that a subnet's host_routes would default to [ { 'destination': 0.0.0.0/0, nexthop: <gateway-ip>}], but someone who wanted a gateway that was not a default gateway could specify host routes that did include a default route, and instead just had a more specific route, for example: [ {'destination': '172.16.19.0./24', 'nexthop': <gateway-ip>}]

It seems like the current logic in db_base_plugin_v2.py doesn't create any route by default, and so as a result, dnsmasq generates one every time, putting us in the situation we see here.

Thinking a bit more, I think there's even a single VIF case where this applies. What if you wanted a private network that was just uplinked to a remote subnet in another data center, but was not supposed to have a default gateway at all. Even with the current change, I think its impossible to have a gateway-ip and not have it be the default gateway.

Does this issue make sense to people? Are there other suggestions on how we should handle it?

Reviewed: https://review.openstack.org/12394
Committed: http://github.com/openstack/quantum/commit/bb68d9c93ef391e68e3752a4b7af1f06dffc4418
Submitter: Jenkins
Branch: master

commit bb68d9c93ef391e68e3752a4b7af1f06dffc4418
Author: Mark McClain <email address hidden>
Date: Wed Sep 5 00:27:27 2012 -0400

    supress dhcp router opt for subnets with null gw

    fixes bug 1045617

    This patch supresses the default gateway for subnets without gateway
    defined.

    Change-Id: I29d84863e51f613d8529153870eb7542d992be0e

Since this patch merged, the current logic supports your scenarios. The only difference is that the gateway_ip treated separately and pushed as the default route iff it is defined. Regardless of the value for gateway_ip dnsmasq will send host_routes for non default routing options if the client requests it.

Are you advocating that we only define the default route in host_routes and drop gateway_ip? If so, we'll have to add logic to convert that route to option 3 because some clients don't request option 121 (Cirros).