<div dir="ltr">Hi, <div><br></div><div>see my comments inline:</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 4:11 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"><div class="gmail_quote"><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<br></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">Is this blueprint not yet implemented?  When I attempt to create multiple VIPs using the same IP in my test cluster, I get:</div>

<div style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></div><div><font face="arial, sans-serif">sbalukoff@testbox:~$ neutron lb-vip-create --name test-vip2 --protocol-port 8000 --protocol HTTP --subnet-id a4370142-dc49-4633-9679-ce5366c482f5 --address 10.48.7.7 test-lb2</font><br>

</div><div><font face="arial, sans-serif">Unable to complete operation for network aa370a26-742d-4eb6-a6f3-a8c344c664de. The IP address 10.48.7.7 is in use.</font><br></div><div><font face="arial, sans-serif"><br></font></div>

<div><font face="arial, sans-serif">From that, I gathered there was a uniqueness check on the IP address.</font></div></div></div></div></blockquote><div> </div><div>No, it's not yet implemented. Currently VIP creation implies port creation, so in order to create VIP on the same IP, the port should be shared between them, and that is blocked by existing implementation of haproxy driver.</div>
<div>We're now working on addressing that.</div><div><br></div><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"><div class="gmail_quote">
<div><br></div><div><font face="arial, sans-serif">Regardless of the above:  I think splitting the concept of a 'VIP' into 'instance' and 'listener' objects has a couple other benefits as well:</font></div>

<div><font face="arial, sans-serif"><br></font></div><div><ul><li><span style="font-family:arial,sans-serif">You can continue to do a simple uniqueness check on the IP address, as only one instance should have a given IP.<br>

</span><br></li><li><span style="font-family:arial,sans-serif">The 'instance' object can contain a 'tenant_id' attribute, which means that at the model level, we enforce the idea that a given floating IP can only be used by one tenant (which is good, from a security perspective).<br>

</span><br></li><li><span style="font-family:arial,sans-serif">This seems less ambiguous from a terminology perspective. The name 'VIP' in other contexts means 'virtual IP address', which is the same thing as a floating IP, which in other contexts is usually considered to be unique to a subset of devices that share the IP (or pass it between them). It doesn't necessarily have anything to do with layers 4 and above in the OSI model. However, if in the context of Neutron LBaaS, "VIP" has a "protocol-port" attribute, this means it's no longer just a floating IP:  It's a floating IP + TCP port (plus other attributes that make sense for a TCP service). This feels like Neutron LBaaS is trying to redefine what a "virtual IP" is, and is in any case going to be confusing for new comers expecting it to be one thing when it's actually another.</span></li>
</ul></div></div></div></div></blockquote><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></div></div></div>