Add extraroutes support to neutron routers

Use Case:

             OpenStack Managed
-------------------------------------------
                   ================|
                   | TENANT ROUTER |
                   ================|
 ------------------------------------|------
                                                 |
                                                 | EXTERNAL NETWORK
| VPN TERMINATOR |--------|
                                                 |
                                                 |
                                                 |
                                          ======
                                          | GW |
                                          ======

There are cases where the tenant router needs an additional route to direct traffic for a network to a device other than the default gateway on the external network (e.g. the VPN terminator above). Being on the external network, these devices are likely not managed by OpenStack and have no UUID identifier or corresponding Neutron port.

Neutron has an extra routes extension to allow these routes to be added in the form of (CIDR, nexthop IP address). This blueprint is to bring support for this extension to heat.

Gerrit topic: https://review.openstack.org/#q,topic:bp/router-properties-object,n,z

Addressed by: https://review.openstack.org/41044
    Adds router properties object to allow extra routes

(zaneb) So, we already have VPN resources in Heat that _do_ have UUIDs, so it's not clear to me why there would be endpoints that exist completely outside of OpenStack's knowledge that we would want to talk to. In fact, arguably the solution to this particular use case could be to add a list of routes to handle to the VPN resource and have it call the ExtraRoutes API, rather than exposing that API directly.

(kbenton) That would work if it were a VPN resource created and controlled by neutron; however, that's not the case here. Additionally, it could just be another external router (or a packet logging device, etc), in which case it doesn't make any sense to model it as a neutron VPN. The tenant router is under the control of neutron and setting extra static routes is a common task when integrating with existing networks or special network devices.

(kanabuchi) Please give me a chance to say my opinion. I understood what Kevin said, the necessity of ExtraRoute is for supporting physical network devices. I think this support is really important one. A lot of common network device's functionality supported in currently neutron. However, apart from this a lot of physical network devices that has another functionality are. (Kevin said packet logging device is one of example). Additionally, I think functionality, availability and capacity is different between physical network devices and virtual network devices. This matter should be decide by IaaS designer from their consideration. So, I think ExtraRoutes need for providing option to IaaS designer.

(zaneb) This was discussed at the Heat meeting on 2014-02-06: http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-02-06-00.00.html
It appears that what kanabuchi is talking about is useful only for operators deploying OpenStack, and not for end users. (It's unclear if this has been kbenton's intention all along?) Given that this _can't_ work in Heat's resource model (because it relies on resources that are external to OpenStack and have no representation in the template, I personally don't see any point in having it in Heat. But if operators want it, I would not be opposed to carrying this plugin in /contrib - operators, unlike end users, have the flexibility to install whatever plugins they like. The resource model in the current proposed patch remains, in my opinion, broken and should not be exposed to end users. If there are remaining use cases for end users to make use of Extra Routes then we need to come up with a model for them that actually results in a correct orchestration - likely by dealing with each individual use case separately rather than modelling the Extra Routes API directly.

(kbenton) The use case I'm talking about is not for operators deploying OpenStack. It's for tenants. These routes are a property of tenant routers which are created and deleted by the tenants. Unfortunately, it's not a CRUD interface. It's just an optional neutron extension to accept routes as part of a router update operation. Referring to the use-case, this patch would allow the tenant to send traffic for a certain CIDR via a VPN terminator instead of the default gateway. Without this
patch, this isn't possible to configure via a template. Is the fundamental issue that you don't want
tenants to be able to configure arbitrary routes on their routers?