[openstack-dev] [Fuel] Change VIP address via API

Aleksey Kasatkin akasatkin at mirantis.com
Mon Nov 2 16:07:11 UTC 2015


Hi folks,

I'm working on the following story [1][2]:
API must allow VIP to be manually set to ANY valid IP address. If the IP on
update API is a member of any network in this environment then the address
should be put in the assignments table so that it can not be used in any
other
automatic assignment. (This allows the user to override if the automatic
allocation doesn't match their needs or in the case that they want to use
external LB).

[1] https://bugs.launchpad.net/fuel/+bug/1482399
[2] https://review.openstack.org/230943

So, I have the following proposal for now:
Add new url (e.g. /clusters/<cluster_id>/network_configuration/vips/ ), use
GET
to query current VIPs info, use PUT to change VIPs addresses (set them
manually
or request to allocate them automatically).
Now VIPs have the following format in API requests data:
vips: [
    {
        'network_role': 'management',
        'namespace': 'haproxy',
        'ipaddr': '10.10.10.10',
        'node_roles': ['controller']
    },...
]
So, 'ipaddr' field can be set to any (almost any) user-defined value or to
None (null in YAML).
When it is set to None, IP address will be allocated automatically. When
the user runs GET
request for the first time, all 'ipaddr' fields are equal to None. So, user
can set some (or all)
of them to desired values and run PUT. When the GET is run after PUT, all
addresses will be
filled with values. User can reset some of them to None or change to other
IP when required.
So, addresses will be re-allocated on the next PUT requests.
If address given by user overlaps with some of the allocated IPs, PUT
request will be rejected.
There is a question, what to do when the given address overlaps with the
network from another
environment? overlaps with the network of current environment which does
not match the
network role of the VIP?
My opinion that those should pass with a warning message.

Please share your proposals and comments on this,

Thanks,


Aleksey Kasatkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151102/fd866747/attachment.html>


More information about the OpenStack-dev mailing list