Listeners with same name cause virtual server IP to be changed

[abattye]

We are seeing an issue when multiple load balancers are created in a project with the same listener name. In Neutron these listeners are created as separate entities with different UUIDs but on the F5 side only one virtual server is created with the listener name. As new LB/Listeners are created the virtual server is constantly updated to use the IP of the last listeners LB.

Obviously this is a major issue, since any LB scenario in use stops working after the virtual server IP is changed. Our expectation is that objects in F5 would be created with some unique ID reflecting the object created in Neutron and duplicate names within a project would not cause such issues.

This is a major blocker for us - especially as we expect an fix would have potential backward compatibility issues if the identifier in F5 has to change.

We are on driver/agent v9.0.1 with stable/mitaka neutron/neutron-lbaas

Its easy to reproduce

create load balancer lb1 create new listener l1, attached to lb1 Check F5 - the virtual server l1 will have the IP of lb1 create load balancer lb2 create new listener l1, attached to lb2 Check F5 - the virtual server l1 will have the IP of lb2 Any access load balanced content from the IP of lb1 will fail.

[richbrowne]

We have a solution for your problem and it was submitted into Liberty and Mitaka. It will be available in the upcoming release. A new algorithm is used to name the F5 objects with the UUID of the OS object.

This requires the services that were deployed be renamed to the new naming scheme. At startup the agent looks for the loadbalancers that neutron has bound to it, it will remove all objects that have the non-unique name and redeploy the service using the new names.

This does result in some pain as there will be a short outage for the service when the object is renamed.

[abattye]

Thanks Rich, especially pleased to hear the renaming is handled .

I'm not sure if its related, but we are also seeing issues deleting objects (so far only reproduced with the 'same name' issue) - the API responds saying the object is deleted, but its persisted both in neutron and F5 - I try to get more details and will open a separate issue if required, unless you are aware of the problem already. Current we have to clean out the DB and F5 config manually.

[richbrowne]

I believe that they are related because the duplicate names could make it appear as though we are deploying a meld of services on the BigIP; however, when a deletion event occurs that was originated from Neutron, the service as described by the event is not in agreement with the BigIP view of the virtual causing only a portion of the service to be deleted, but leaving the neutron database in an inconsistent state. I would expect to see an error in the agent log that indicates an object could not be deleted because another object holds a reference to it.

If you have any more information like logs or the state of the partition on the BigIP, you can add those to this issue and I will examine them.

We are scheduled to release a beta-version 9.2 in the next week that will have this solution. If you have any questions, you may contact me directly. I am writing instructions on how customers should proceed before upgrading to this new release and will pass them along to you if you wish to comment.

[dflanigan]

This is a duplicate of issue #329

[abattye]

I'm not sure its just a duplicate, I am also seeing issues deleting both pools and pool members when there is no duplicate name in neutron.

I call something like neutron lbaas-member-delete 57002275-ed5c-4b30-b170-38523034a104 p1 and neutron lbaas-pool-delete p1 and in both cases the member/pool is reported as deleted by the API response. However, they remain in both neutron and F5.

[mattgreene]

@abattye: Are you still seeing this problem? The plan was to retest after upgrading to the new packages with the service-renaming changes.

[abattye]

I think the recent release fixes these issue. Thanks.