Management of VSM network interface about maya HOT 1 CLOSED

The VSM IP needs to remain static (sticky) today, because the client that is connected to VSM IP may not know that IP address has changed due to HA or Migration.

The workflow is as follows:
(1) When VSM is created, an IP is allocated on the required network segment ( subnet/vlan)
(2) This allocated IP needs to be persisted ( in nameserver for service discovery) and accessible via the API / command response to pass on to the client.
(3) The client connects using the IP
(4) HA/Migration causes the VSM to be moved to another node
(5) The IP on the old node needs to be cleared ( if node is still online)
(6) The IP needs to be created on the new node, before the VSM is started

To support this use case in the current scheme of things, where we don't have post/pre hooks for nomad docker containers, i will be using a wrapper approach that will do the (2),(5),(6).

hashicorp/nomad#1061
https://gist.github.com/ketzacoatl/3ccf5bb822df51aed2b896641e931c8a
https://github.com/FRosner/nomad-docker-wrapper
http://stackoverflow.com/questions/34688906/how-to-assign-static-public-ip-to-docker-container

(Also when we get the flannel or any other networking plugin working, we will need to modify it to allow for sticky IPs. This is currently not on the road-maps for containers-network-plugins. )

In the future, we may be eliminate this Sticky IP Requirement for VSMs, if the client can use the "service discovery" of the container world or "iSNS" to know of the VSM IP

(a) When VSM is created, an IP is allocated on the required network segment ( subnet/vlan)
(b) This allocated IP needs to be persisted ( for service discovery)
(c) The client is passed an domain name (key) for the volume and it uses the iSNS or Service discovery to know the IP address to connect to.
(d) On HA/Migration the VSM can come up on new up and it will update - name server/iSNS. Client will reconnect with the updated IP address.

For the containers use-case, the above can be implemented because maya-driver can query for the VSM IP address and reconnect.
For non-container cases, where client side driver is not available - we can use the iSCSI - iSNS functionality (This is what I think solidfire uses).
For use cases, where VSM can move across environments like hybrid-cloud, the domain name based option may become mandatory.

Is there any case where this changed implementation can become a bottleneck?
Is there any better way to eliminate this sticky IP requirement? ( using a client side load-balancer .. but requires that the VSM comes up from a pool of IPs allocated during creation )

from maya.