Assaf, It would be helpful if these notes were on the reviews [1]. I think there are concerns in this email that I have not noticed in the review. Maybe I missed them.
Carl [1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability On Mon, Feb 24, 2014 at 8:58 AM, Assaf Muller <amul...@redhat.com> wrote: > Hi everyone, > > A few concerns have popped up recently about [1] which I'd like to share and > discuss, > and would love to hear your thoughts Sylvain. > > 1) Is there a way through the API to know, for a given router, what agent is > hosting > the active instance? This might be very important for admins to know. > > 2) The current approach is to create an administrative network and subnet for > VRRP traffic per router group / > per router. Is this network counted in the quota for the tenant? (Clearly it > shouldn't). Same > question for the HA ports created for each router instance. > > 3) The administrative network is created per router and takes away from the > VLAN ranges if using > VLAN tenant networks (For a tunneling based deployment this is a non-issue). > Maybe we could > consider a change that creates an administrative network per tenant (Which > would then limit > the solution to up to 255 routers because of VRRP'd group limit), or an admin > network per 255 > routers? > > 4) Maybe the VRRP hello and dead times should be configurable? I can see > admins that would love to > up or down these numbers. > > 5) The administrative / VRRP networks, subnets and ports that are created - > Will they be marked in any way > as an 'internal' network or some equivalent tag? Otherwise they'd show up > when running neutron net-list, > in the Horizon networks listing as well as the graphical topology drawing > (Which, personally, is what > bothers me most about this). I'd love them tagged and hidden from the normal > net-list output, > and something like a 'neutron net-list --all' introduced. > > 6) The IP subnet chosen for VRRP traffic is specified in neutron.conf. If a > tenant creates a subnet > with the same range, and attaches a HA router to that subnet, the operation > will fail as the router > cannot have different interfaces belonging to the same subnet. Nir suggested > to look into using > the 169.254.0.0/16 range as the default because we know it will (hopefully) > not be allocated by tenants. > > [1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability > > > Assaf Muller, Cloud Networking Engineer > Red Hat > > _______________________________________________ > OpenStack-dev mailing list > 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
