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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev