Hello!
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 10.48.7.7 test-lb2
Unable to complete operation for network
aa370a26-742d-4eb6-a6f3-a8c344c664de. The IP address 10.48.7.7 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.
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
