Open Stack

Hi Eugene,

Aah, Ok. FWIW, splitting up the VIP into instance/"floating IP entity"
separate from listener (ie. carries most of the attributes of VIP, in
current implementation) still allows us to ensure tenants don't end up
accidentally sharing an IP address. The "instance" could be associated with
the neutron network port, and the haproxy listeners (one process per
listener) could simply be made to listen on that port (ie. in that network
namespace on the neutron node). There wouldn't be a need for two instances
to share a single neutron network port.

Has any thought been put to preventing tenants from accidentally sharing an
IP if we stick with the current model?

Stephen


On Thu, Feb 13, 2014 at 4:20 AM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:

> So we have some constraints here because of existing haproxy driver impl,
> the particular reason is that VIP created by haproxy is not a floating ip,
> but an ip on the internal tenant network with a neutron port. So ip
> uniqueness is enforced at port level and not at VIP level. We need to allow
> VIPs to share the port, that is a part of multiple-vips-per-pool blueprint.
>
> Thanks,
> Eugene.
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/5e08ef32/attachment.html>