[openstack-dev] [neutron] Extraroute and router extensions
Rudra Rugge
rrugge at juniper.net
Wed Oct 9 20:56:37 UTC 2013
Hi Salvatore,
Thanks for your comments. I agree backward compatibility would be the most important aspect and the change can be managed accordingly.
Regarding host_routes in subnet:
Do we need to keep host_routes in the subnet - could this be moved to extraroutes extension and linked back to subnets, networks, routers.
Also I have published an IPAM blueprint which covers decoupling of information from the subnet so that the resource management of DNS, DHCP, address allocation schemes is not dependent on networks as it is today with subnet resource.
https://wiki.openstack.org/wiki/Blueprint-ipam-extensions-for-neutron
Regards,
Rudra
On Oct 9, 2013, at 11:43 AM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:
Hi Rudra,
Some comments inline.
Regards,
Salvatore
Il 09/ott/2013 19:27 "Rudra Rugge" <rrugge at juniper.net<mailto:rrugge at juniper.net>> ha scritto:
>
> Updated the subject [neutron]
>
> Hi All,
>
> Is the extra route extension always tied to the router extension or
> can it live in a separate route-table container. If extra-route routes
> are available in separate container then sharing of such
> containers across networks is possible.
At this stage it is just an attribute of the router resource even if they're then implemented in their own database model. Making them reusable across routers (or networks as you suggest) is feasible, provided that we also have a solution to ensure backwards compatibility.
>
> Another reason to remove the dependency would be to have
> next hops that are not CIDRs. Next-hops should be allowed as
> interface or a VM instance such as NAT instance. This would
> make the extra route extension more generic.
It should not be excessively hard generalizing the nexthop attribute without breaking compatibility. I reckon this can be done independently from splitting extra routes into a first level resource.
>
> This way an extra-route container can be attached/bound to
> either a router extension or to a network as well. Many plugins
> do not need a separate router entity for most of the inter-network
> routing.
Indeed. As you surely are already aware, the subnet resource has a similar attribute for routes to be distributed to instances via DHCP.
>
> Thanks,
> Rudra
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/22d6e7d7/attachment.html>
More information about the OpenStack-dev
mailing list