[openstack-dev] [Fuel] Change VIP address via API
Aleksey Kasatkin
akasatkin at mirantis.com
Tue Dec 29 15:09:37 UTC 2015
Folks, you are welcome to review a spec: https://review.openstack.org/254796
Aleksey Kasatkin
On Fri, Nov 6, 2015 at 6:03 PM, Aleksey Kasatkin <akasatkin at mirantis.com>
wrote:
> Mike, Vladimir,
>
> Yes,
> 1. We need to add IPs on-the-fly (need to add POST functionality) ,
> otherwise it will be VIP-like way (change network roles in plugin or
> release).
> 2. We should allow to leave fields 'network_role', 'node_roles', 'namespace'
> empty. So, validation should be changed.
>
> So, answer here
>
>> Q. Any allocated IP could be accessible via these handlers, so now we can
>> restrict user to access VIPs only
>> and answer with some error to other ip_addrs ids.
>>
> should be "Any allocated IP is accessible via these handlers", so URLs can
> be changed to
> /clusters/<cluster_id>/network_configuration/ips/
> /clusters/<cluster_id>/network_configuration/ips/<id>/
> Nodes IPs maybe the different story though.
>
> Alex,
>
> 'node_roles' determines in what node group to allocate IP. So, it will be
> group with controller nodes for our base VIPs
> (they all have node_roles=['controller'] which is default setting).
> It can be some other node group for nodes with different role. E.g. ceph
> nodes use some ceph/vip network role and VIP is defined
> for this network role (with 'network_role'='ceph/vip' and 'node_roles'=['ceph/osd']).
> This VIP will be allocated
> in the network that 'ceph/vip' is mapped to and in the node group where
> ceph nodes are located. ceph nodes cannot be located
> in more than one node group then (as VIP cannot migrate between node groups
> now).
>
>
>
> Aleksey Kasatkin
>
>
> On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin <vkuklin at mirantis.com>
> wrote:
>
>> +1 to Mike
>>
>> It would be awesome to get an API handler that allows one to actually add
>> an ip address to IP_addrs table. As well as an IP range to ip_ranges table.
>>
>> On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov <mscherbakov at mirantis.com
>> > wrote:
>>
>>> Is there a way to make it more generic, not "VIP" specific? Let's say I
>>> want to reserve address(-es) for something for whatever reason, and then I
>>> want to use them by some tricky way.
>>> More specifically, can we reserve IP address(-es) with some codename,
>>> and use it later?
>>> 12.12.12.12 - my-shared-ip
>>> 240.0.0.2 - my-multicast
>>> and then use them in puppet / whatever deployment code by $my-shared-ip,
>>> $my-multicast?
>>>
>>> Thanks,
>>>
>>> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin <akasatkin at mirantis.com>
>>> wrote:
>>>
>>>> Folks,
>>>>
>>>> Here is a resume of our recent discussion:
>>>>
>>>> 1. Add new URLs for processing VIPs:
>>>>
>>>> /clusters/<cluster_id>/network_configuration/vips/ (GET)
>>>> /clusters/<cluster_id>/network_configuration/vips/<id>/ (GET, PUT)
>>>>
>>>> where <id> is the id in ip_addrs table.
>>>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>>>> address) for one VIP by its id.
>>>> More possibilities can be added later.
>>>>
>>>> Q. Any allocated IP could be accessible via these handlers, so now we
>>>> can restrict user to access VIPs only
>>>> and answer with some error to other ip_addrs ids.
>>>>
>>>> 2. Add current VIP meta into ip_addrs table.
>>>>
>>>> Create new field in ip_addrs table for placing VIP metadata there.
>>>> Current set of ip_addrs fields:
>>>> id (int),
>>>> network (FK),
>>>> node (FK),
>>>> ip_addr (string),
>>>> vip_type (string),
>>>> network_data (relation),
>>>> node_data (relation)
>>>>
>>>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>>>
>>>> 3. Allocate VIPs on cluster creation and seek VIPs at all network
>>>> changes.
>>>>
>>>> So, VIPs will be checked (via network roles descriptions) and
>>>> re-allocated in ip_addrs table
>>>> at these points:
>>>> a. create cluster
>>>> b. modify networks configuration
>>>> c. modify one network
>>>> d. modify network template
>>>> e. change nodes set for cluster
>>>> f. change node roles set on nodes
>>>> g. modify cluster attributes (change set of plugins)
>>>> h. modify release
>>>>
>>>> 4. Add 'manual' field into VIP meta to indicate whether it is
>>>> auto-allocated or not.
>>>>
>>>> So, whole VIP description may look like:
>>>> {
>>>> 'name': 'management'
>>>> 'network_role': 'mgmt/vip',
>>>> 'namespace': 'haproxy',
>>>> 'node_roles': ['controller'],
>>>> 'alias': 'management_vip',
>>>> 'manual': True,
>>>> }
>>>>
>>>> Example of current VIP description:
>>>>
>>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>>>>
>>>> Nailgun will re-allocate VIP address if 'manual' == False.
>>>>
>>>> 5. Q. 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?
>>>>
>>>> Use '--force' parameter to change it. PUT will fail otherwise.
>>>>
>>>>
>>>> Guys, please review this and share your comments here,
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Aleksey Kasatkin
>>>>
>>>>
>>>> On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin <
>>>> akasatkin at mirantis.com> wrote:
>>>>
>>>>> Igor,
>>>>>
>>>>> > For VIP allocation we should use POST request. It's ok to use PUT
>>>>> for setting (changing) IP address.
>>>>>
>>>>> My proposal is about setting IP addresses for VIPs only (auto and
>>>>> manual).
>>>>> No any other allocations.
>>>>> Do you propose to use POST for first-time IP allocation and PUT for IP
>>>>> re-allocation?
>>>>> Or use POST for adding entries to some new 'vips' table (so that all
>>>>> VIPs descriptions
>>>>> will be added there from network roles)?
>>>>>
>>>>> > We don't store network_role, namespace and node_roles within VIPs.
>>>>> > They are belonged to network roles. So how are you going to retrieve
>>>>> > them? Did you plan to make some changes to our data model? You know,
>>>>> > it's not a good idea to make connections between network roles and
>>>>> > VIPs each time your make a GET request to list them.
>>>>>
>>>>> It's our current format we use in API when VIPs are being retrieved.
>>>>> Do you propose to use different one for address allocation?
>>>>>
>>>>> > Should we return VIPs that aren't allocated, and if so - why? If they
>>>>> > would be just, you know, fetched from network roles - that's a bad
>>>>> > design. Each VIP should have an explicit entry in VIPs database
>>>>> table.
>>>>>
>>>>> I propose to return VIPs even w/o IP addresses to show user what VIPs
>>>>> he has
>>>>> so he can assign IP addresses to them. Yes, I supposed that the
>>>>> information
>>>>> will be retrieved from network roles as it is done now. Do you propose
>>>>> to create
>>>>> separate table for VIPs or extend ip_addrs table to store VIPs
>>>>> information?
>>>>>
>>>>> > We definitely should handle `null` this way, but I think from API POV
>>>>> > it would be more clearer just do not pass `ipaddr` value if user
>>>>> wants
>>>>> > it to be auto allocated. I mean, let's keep `null` as implementation
>>>>> > details ans force API users just do not pass this key if they don't
>>>>> > want to.
>>>>>
>>>>> Oh, I didn't write it here, I thought about keeping IP addresses as is
>>>>> when
>>>>> corresponding key is skipped by the user.
>>>>>
>>>>> >The thing is that there's no way to *warn* users through API. You
>>>>> > could either reject or accept request. So all we can do is to
>>>>> > introduce some `force` flag, and if it's passed - ignore overlapping.
>>>>>
>>>>> It is now done for network verification that it can pass with warning
>>>>> message.
>>>>> But I like your proposal better.
>>>>>
>>>>> > overlaps with the network of current environment which does not
>>>>> > match the network role of the VIP?
>>>>>
>>>>> So, when IP address of the VIP matches some IP range that corresponds
>>>>> to the network which is different from the one that network role bound
>>>>> to the VIP has.
>>>>> E.g. IP address matches the 'public' network but VIP is bound to
>>>>> 'management/vip' role
>>>>> which is mapped to 'management' network.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Aleksey Kasatkin
>>>>>
>>>>>
>>>>> On Mon, Nov 2, 2015 at 7:06 PM, Igor Kalnitsky <
>>>>> ikalnitsky at mirantis.com> wrote:
>>>>>
>>>>>> Hey Aleksey,
>>>>>>
>>>>>> I agree that we need a separate API call for VIP allocation, thought I
>>>>>> don't agree on some points you have proposed. See my comments below.
>>>>>>
>>>>>> > use PUT to change VIPs addresses (set them manually or request
>>>>>> > to allocate them automatically)
>>>>>>
>>>>>> PUT requests SHOULD NOT be used for VIP allocation, by RESTful API
>>>>>> notation the PUT request should be used for changing (editing)
>>>>>> entities, not for creating new ones. For VIP allocation we should use
>>>>>> POST request. It's ok to use PUT for setting (changing) IP address.
>>>>>>
>>>>>> > vips: [
>>>>>> > {
>>>>>> > 'network_role': 'management',
>>>>>> > 'namespace': 'haproxy',
>>>>>> > 'ipaddr': '10.10.10.10',
>>>>>> > 'node_roles': ['controller']
>>>>>> > },...
>>>>>> > ]
>>>>>>
>>>>>> There I have two comments:
>>>>>>
>>>>>> * We don't need the "vips" word in API output - let's return a JSON
>>>>>> list with VIPs and that's it.
>>>>>> * We don't store network_role, namespace and node_roles within VIPs.
>>>>>> They are belonged to network roles. So how are you going to retrieve
>>>>>> them? Did you plan to make some changes to our data model? You know,
>>>>>> it's not a good idea to make connections between network roles and
>>>>>> VIPs each time your make a GET request to list them.
>>>>>>
>>>>>> > When it is set to None, IP address will be allocated automatically
>>>>>>
>>>>>> We definitely should handle `null` this way, but I think from API POV
>>>>>> it would be more clearer just do not pass `ipaddr` value if user wants
>>>>>> it to be auto allocated. I mean, let's keep `null` as implementation
>>>>>> details ans force API users just do not pass this key if they don't
>>>>>> want to.
>>>>>>
>>>>>> > When the user runs GET request for the first time, all 'ipaddr'
>>>>>> > fields are equal to None.
>>>>>>
>>>>>> Should we return VIPs that aren't allocated, and if so - why? If they
>>>>>> would be just, you know, fetched from network roles - that's a bad
>>>>>> design. Each VIP should have an explicit entry in VIPs database table.
>>>>>>
>>>>>> > There is a question, what to do when the given address overlaps
>>>>>> > with the network from another environment? My opinion that those
>>>>>> > should pass with a warning message.
>>>>>>
>>>>>> The thing is that there's no way to *warn* users through API. You
>>>>>> could either reject or accept request. So all we can do is to
>>>>>> introduce some `force` flag, and if it's passed - ignore overlapping.
>>>>>>
>>>>>> I didn't get what do you mean by:
>>>>>>
>>>>>> > overlaps with the network of current environment which does not
>>>>>> > match the network role of the VIP?
>>>>>>
>>>>>> Could you please explain?
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> P.S: I see this API call somehow this way
>>>>>> http://xsnippet.org/361113/raw/
>>>>>>
>>>>>> On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin <
>>>>>> akasatkin at mirantis.com> wrote:
>>>>>> > 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-request at lists.openstack.org?subject:unsubscribe
>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> >
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> --
>>> Mike Scherbakov
>>> #mihgen
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuklin at mirantis.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151229/ec71b98b/attachment.html>
More information about the OpenStack-dev
mailing list