Open Stack

Hi,

Mike, that's exactly how you can use this VIPs allocation functionality.
Nailgun will save that VIP so it's not going to be auto-assigned to any
node and serialize it into astute.yaml (vip_name: IP). After that you can
get your VIP via Hiera and use it in your deployment scripts.

Guys, could you please clarify what's the purpose of 'node_roles' in VIP
description?

Regards,
Alex

On Fri, Nov 6, 2015 at 5: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151106/fa39dc6b/attachment.html>