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 <sorla...@nicira.com<mailto:sorla...@nicira.com>> wrote: Hi Rudra, Some comments inline. Regards, Salvatore Il 09/ott/2013 19:27 "Rudra Rugge" <rru...@juniper.net<mailto:rru...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
