This e-mail is concerning the "Multiple load balanced services per floating
IP" feature:

Sam, I think you said:

On Tue, Feb 11, 2014 at 5:26 AM, Samuel Bercovici <samu...@radware.com>wrote:

> ยท         Multiple load balanced services per floating IP     - You can
> already multiple VIPs using the same IP address for different services.
And Eugene said:

> Multiple load balanced services per floating IP
That is what blueprint 'multiple vips per pool' is trying to address.

Is this blueprint not yet implemented?  When I attempt to create multiple
VIPs using the same IP in my test cluster, I get:

sbalukoff@testbox:~$ neutron lb-vip-create --name test-vip2 --protocol-port
8000 --protocol HTTP --subnet-id a4370142-dc49-4633-9679-ce5366c482f5
--address test-lb2
Unable to complete operation for network
aa370a26-742d-4eb6-a6f3-a8c344c664de. The IP address is in use.

>From that, I gathered there was a uniqueness check on the IP address.

If this has been implemented previously, could y'all point me at a working
example showcasing the CLI or API commands used to create multiple services
per floating IP (or just point out to me what I'm doing wrong)?

Regardless of the above:  I think splitting the concept of a 'VIP' into
'instance' and 'listener' objects has a couple other benefits as well:

   - You can continue to do a simple uniqueness check on the IP address, as
   only one instance should have a given IP.

   - 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).

   - 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.


Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
OpenStack-dev mailing list

Reply via email to