Open Stack

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/68ecb409/attachment.html>