neutron

[LBaaS] pools' subnet_id and members

Asked by Ivar Lazzaro

Hello,

There's a question that's bothering me about LBaaS APIs.
According to the documentation, the "subnet_id" param for pools is representing "the network that the pool members belong to", but when using the extension through Horizon (devstack installation) it actually doesn't limit me in setting members belonging to different subnets within the same Pool.

Furthermore, when creating a VIP associated to that pool, it's asking me to specify a free address from the subnet specified in the pool.

Soooo which one is the expected behavior? :)

Thanks

Question information

Language:
English Edit question
Status:
Solved
For:
neutron Edit question
Assignee:
No assignee Edit question
Solved by:
Eugene Nikanorov
Solved:
Last query:
Last reply:
Revision history for this message
Best Eugene Nikanorov (enikanorov) said : 		#1

Those are artifacts of current implementation.
So in fact the only actual requirement is that address should be routable from the VIP.
Horizon may enforce it in it's way.

Regarding the VIP - theoretically, VIP can be on the other subnet.
This is just other insertion mode for the loadbalancer than what is implemented now.
It's not supported at this moment, but will be supported later.

Also, there is https://bugs.launchpad.net/quantum/+bug/1177200 to clean this up.

Revision history for this message
Ivar Lazzaro (mmaleckk) said : 		#2

Thanks Eugene,

Still I don't get what is the meaning of the Pool "subnet_id" though... Since it is not used either to validate members nor to enforce the VIP subnet...

Moreover, the members are represented only by their IP address (no port/subnet/network id) so there may be problems when trying to understand in which quantum network the actual instance is set. A load balancer which needs to create a port to reach that instance wouldn't know for sure the network id in which the port shall be created.

However, seeing https://bugs.launchpad.net/quantum/+bug/1177200 though, those are probably things that will be settled soon.
Do you already have an idea of what kind of behavior we should expect? Member validation? Or getting rid of the Pool subnet_id, giving a way to understand the network to which each member belongs?

Revision history for this message
Ivar Lazzaro (mmaleckk) said : 		#3

Thanks Eugene Nikanorov, that solved my question.