Open Stack

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 <amuller at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev