Open Stack

Hi,

see my comments inline:


On Thu, Feb 13, 2014 at 4:11 AM, Stephen Balukoff <sbalukoff at bluebox.net>wrote:

>
>
> Is this blueprint not yet implemented?  When I attempt to create multiple
> VIPs using the same IP in my test cluster, I get:
>
> sbalukoff at 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.
>

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.
We're now working on addressing that.


> 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.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/d238a04b/attachment.html>