<div dir="ltr">Stephen,<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> Aah, Ok. FWIW, splitting up the VIP into instance/"floating IP entity" </span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">Right now I'm not sure what would be the best. Currently we don't have implementation that allows creating VIP on external network directly. For example, when haproxy VIP is created, it has address on the tenant network and floating ip is associated with vip address then. Other providers could allow creating VIP on external network directly.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>Basically tenants can't share floating ip because they can't specify floating IP on external network.</div><div>However, VIP address may or may not be internet facing. If it's internal address on tenant network then nothing prevents another tenant from having vip with the same ip address on it's own tenant network. However internet-facing addresses will obviously be different.<br>
</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 3:57 AM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Eugene,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Has any thought been put to preventing tenants from accidentally sharing an IP if we stick with the current model?</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">
<br></div><div class="gmail_extra">
Stephen</div><div class="gmail_extra"><br></div></font></span><div class="gmail_extra"><div class=""><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 4:20 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>


<div><br></div><div>Thanks,</div><div>Eugene.</div></blockquote></div><br clear="all"><div><br></div></div><div class="">-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>