How to Prevent floating IP reassignment
I have a question regarding using the Associate Floating IP flow
Using the flow above, I can assign floating ip to a server.
Below there is my use case;
I have couple of Associate Floating IP flows parallel started from Market Place Portal.
I see that "Associate Floating IP" flow first get the available floating ip list from openstack.
And parallel flows query the floating ips around the same time. Then they request the same floating ip to be assigned to different
server. Both succeed, but the last one wins .
I have researched a bit and also made some post api directly to openstack services to dig in further. I see that openstack does not have mechanism like
"Hey, this floating ip has jut been assigned to another instance, try again with different floating ip address".
I am looking a way to prevent this by OO flows?
Is this possible? Could you please give some urgent help, as we have this problem in production .
NOTE : I am using HP OO 10.21.0001 .
I'm not positive of the flow you're using, but could you use the Wait for Lock / Release Lock operations around the operations that are stepping on each other as multiple flows both try to assign the same IP? I do something similar when deploying SiteScope monitors and have multiple servers trying to hit SiS at the same time as they're deployed in parallel from CSA.
Thanks for your answer.
Could you please forward me about how can I use Lock / Release Lock within OO flows?
One more question : Do you run OOCentral on a single machine? Because I am using HP Helion Enterprise and oocentral server running on 3 machine with load balancing. I am not sure how can lock for flows runs effectively with 3 oo central.
In the HP Solutions content pack under Library -> Integrations -> Hewlett-Packard -> Operations Orchestration -> 10.x, there are two operations that can be used --- Wait For Lock and Release Lock. Put Wait For Lock before the portions of the flow that other concurrent runs of the same flow should stop at and run sequentially in a way. In your case, it may be before steps that talk to Openstack and ask for the list of available floating IPs to assign, because you want only one flow at a time hitting that step. Then, after the floating IP to use has been identified and allocated to an instance, place the Release Lock step. At that point, any other flows that have hit the same point of wanting to get a list of avialable IP's will be waiting on the Wait for Lock step, and they'll be able to move on since the lock will then be available. For LockID, you can make something up as a constant (6128311528267393869, etc) that is unique to this Wait/Release.
I'm sure there may be other ways to do this, but using locks is how I've gotten around similar situations.
I'd missed the second portion of your question about multiple Central servers. Locks are stored in the database, so I believe even with multiple Central servers you should be OK using them.