<div dir="ltr"><div><div>Folks,<br><br></div>Here is a resume of our recent discussion:<br><br><div class="" id="magicdomid241">1. Add new URLs for processing VIPs:<br></div><div class="" id="magicdomid237"><br></div><div class="" id="magicdomid365"><span class="">/clusters/<cluster_id>/network_configuration/vips/ (GET)</span></div><div class="" id="magicdomid369"><span class="">/clusters/<cluster_id>/network_configuration/vips/<id>/ (GET, PUT)</span></div><div class="" id="magicdomid208"><br></div><div class="" id="magicdomid208">where <id> is the id in ip_addrs table.<br></div><div class="" id="magicdomid208">So, user can get all VIPS, get one VIP by id, change parameters (IP address) for one VIP by its id.<br></div><div class="" id="magicdomid208">More possibilities can be added later.<br></div><div class="" id="magicdomid358"><br>Q. Any allocated IP could be accessible via these handlers, so now we can restrict user to access VIPs only <br>and answer with some error to other ip_addrs ids.<br><br>2.<span class=""> Add current VIP meta into ip_addrs table.<br><br></span></div><div class="" id="magicdomid358"><span class="">Create new field in ip_addrs table for placing VIP metadata there.<br>Current set of ip_addrs fields:<br>id (int), <br>network (FK), <br>node (FK), <br>ip_addr (string), <br>vip_type (string), <br>network_data (relation), <br>node_data </span><span class="">(relation)</span><br></div><div class="" id="magicdomid358"><br>Q. We could replace vip_type (it contains VIP name now) with vip_info.<br></div><div class="" id="magicdomid357"><span class=""><br>3. Allocate VIPs on cluster creation and seek VIPs at all network changes.</span></div><div class="" id="magicdomid356"><br></div><div class="" id="magicdomid356">So, VIPs will be checked (via network roles descriptions) and re-allocated in ip_addrs table <br>at these points:<br></div><div class="" id="magicdomid356">a. create cluster<br></div><div class="" id="magicdomid356">b. modify networks configuration<br></div><div class="" id="magicdomid356">c. modify one network<br></div><div class="" id="magicdomid356">d. modify network template<br></div><div class="" id="magicdomid356">e. change nodes set for cluster<br></div><div class="" id="magicdomid356">f. change node roles set on nodes<br></div><div class="" id="magicdomid356">g. modify cluster attributes (change set of plugins)<br></div><div class="" id="magicdomid356">h. modify release<br></div><div class="" id="magicdomid356"><br></div><div class="" id="magicdomid437"><span class="">4. Add 'manual' field into VIP meta to indicate whether it is auto-allocated or not.</span></div><br></div>So, whole VIP description may look like:<br><div><div class="" id="magicdomid52"><span class="">    {</span></div><div class="" id="magicdomid53"><span class="">        'name': 'management'<br></span></div><div class="" id="magicdomid53"><span class="">        'network_role': 'mgmt/vip',</span></div><div class="" id="magicdomid54"><span class="">        'namespace': 'haproxy',</span></div><span class="">        'node_roles': ['controller'],</span><div class="" id="magicdomid195"><span class="">        'alias': 'management_vip',<br>        'manual': True,<br></span></div><span class="">    }<br><br>Example of current VIP description:<br><a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207</a><br><br></span></div><div><span class="">Nailgun will re-allocate VIP address if 'manual' == False.<br></span></div><div><br></div><div>5. Q. <span class="">what to do when the given address overlaps with the network from another</span><div class="" id="magicdomid131"><span class="">environment? overlaps with the network of current environment which does not match the</span></div><div class="" id="magicdomid155"><span class="">network role of the VIP?</span></div></div><div><br><span class="">Use '--force' parameter to change it. PUT will fail otherwise.<br><br><br></span></div><div><span class="">Guys, please review this and share your comments here,<br><br></span></div><div><span class="">Thanks,<br></span></div><div><br><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin <span dir="ltr"><<a href="mailto:akasatkin@mirantis.com" target="_blank">akasatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Igor, <br><span class=""><br>> For VIP allocation we should use POST request. It's ok to use PUT for setting (changing) IP address.<br><br></span></div>My proposal is about setting IP addresses for VIPs only (auto and manual). <br>No any other allocations.<br>Do you propose to use POST for first-time IP allocation and PUT for IP re-allocation?<br></div>Or use POST for adding entries to some new 'vips' table (so that all VIPs descriptions<br></div>will be added there from network roles)?<br><div><div><span class=""><br>> We don't store network_role, namespace and node_roles within VIPs.<br>
> They are belonged to network roles. So how are you going to retrieve<br>> them? Did you plan to make some changes to our data model? You know,<br>> it's not a good idea to make connections between network roles and<br>> VIPs each time your make a GET request to list them.<div><br></div></span><div>It's our current format we use in API when VIPs are being retrieved.<br></div><div>Do you propose to use different one for address allocation?<span class=""><br><br>> Should we return VIPs that aren't allocated, and if so - why? If they<br>> would be just, you know, fetched from network roles - that's a bad<br>> design. Each VIP should have an explicit entry in VIPs database table.<br></span></div><div><br></div><div>I propose to return VIPs even w/o IP addresses to show user what VIPs he has<br></div><div>so he can assign IP addresses to them. Yes, I supposed that the information <br>will be retrieved from network roles as it is done now. Do you propose to create <br>separate table for VIPs or extend ip_addrs table to store VIPs information?<span class=""><br><br>> We definitely should handle `null` this way, but I think from API POV<br>> it would be more clearer just do not pass `ipaddr` value if user wants<br>> it to be auto allocated. I mean, let's keep `null` as implementation<br>> details ans force API users just do not pass this key if they don't<br>> want to.<br></span></div><div><br></div><div>Oh, I didn't write it here, I thought about keeping IP addresses as is when <br></div><div>corresponding key is skipped by the user.<br></div><span class=""><div><br>>The thing is that there's no way to *warn* users through API. You<br>> could either reject or accept request. So all we can do is to<br>> introduce some `force` flag, and if it's passed - ignore overlapping.<br><br></div></span><div>It is now done for network verification that it can pass with warning message.<br></div><div>But I like your proposal better.<span class=""><br><br><span>> overlaps with the network of current environment which does not<br>
> match the network role of the VIP?</span><br></span></div><div><br></div><div>So, when IP address of the VIP matches some IP range that corresponds<br></div><div>to the network which is different from the one that network role bound to the VIP has.<br></div><div>E.g. IP address matches the 'public' network but VIP is bound to 'management/vip' role <br>which is mapped to 'management' network.<br><br><br></div><div>Thanks,<br><br></div><div><br></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Mon, Nov 2, 2015 at 7:06 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Aleksey,<br>
<br>
I agree that we need a separate API call for VIP allocation, thought I<br>
don't agree on some points you have proposed. See my comments below.<br>
<span><br>
> use PUT to change VIPs addresses (set them manually or request<br>
> to allocate them automatically)<br>
<br>
</span>PUT requests SHOULD NOT be used for VIP allocation, by RESTful API<br>
notation the PUT request should be used for changing (editing)<br>
entities, not for creating new ones. For VIP allocation we should use<br>
POST request. It's ok to use PUT for setting (changing) IP address.<br>
<span><br>
> vips: [<br>
>     {<br>
>         'network_role': 'management',<br>
>         'namespace': 'haproxy',<br>
>         'ipaddr': '10.10.10.10',<br>
>         'node_roles': ['controller']<br>
>     },...<br>
> ]<br>
<br>
</span>There I have two comments:<br>
<br>
* We don't need the "vips" word in API output - let's return a JSON<br>
list with VIPs and that's it.<br>
* We don't store network_role, namespace and node_roles within VIPs.<br>
They are belonged to network roles. So how are you going to retrieve<br>
them? Did you plan to make some changes to our data model? You know,<br>
it's not a good idea to make connections between network roles and<br>
VIPs each time your make a GET request to list them.<br>
<span><br>
> When it is set to None, IP address will be allocated automatically<br>
<br>
</span>We definitely should handle `null` this way, but I think from API POV<br>
it would be more clearer just do not pass `ipaddr` value if user wants<br>
it to be auto allocated. I mean, let's keep `null` as implementation<br>
details ans force API users just do not pass this key if they don't<br>
want to.<br>
<span><br>
> When the user runs GET request for the first time, all 'ipaddr'<br>
> fields are equal to None.<br>
<br>
</span>Should we return VIPs that aren't allocated, and if so - why? If they<br>
would be just, you know, fetched from network roles - that's a bad<br>
design. Each VIP should have an explicit entry in VIPs database table.<br>
<span><br>
> There is a question, what to do when the given address overlaps<br>
</span>> with the network from another environment? My opinion that those<br>
<span>> should pass with a warning message.<br>
<br>
</span>The thing is that there's no way to *warn* users through API. You<br>
could either reject or accept request. So all we can do is to<br>
introduce some `force` flag, and if it's passed - ignore overlapping.<br>
<br>
I didn't get what do you mean by:<br>
<span><br>
> overlaps with the network of current environment which does not<br>
> match the network role of the VIP?<br>
<br>
</span>Could you please explain?<br>
<br>
Thanks,<br>
Igor<br>
<br>
P.S: I see this API call somehow this way <a href="http://xsnippet.org/361113/raw/" rel="noreferrer" target="_blank">http://xsnippet.org/361113/raw/</a><br>
<div><div><br>
On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin <<a href="mailto:akasatkin@mirantis.com" target="_blank">akasatkin@mirantis.com</a>> wrote:<br>
> Hi folks,<br>
><br>
> I'm working on the following story [1][2]:<br>
> API must allow VIP to be manually set to ANY valid IP address. If the IP on<br>
> update API is a member of any network in this environment then the address<br>
> should be put in the assignments table so that it can not be used in any<br>
> other<br>
> automatic assignment. (This allows the user to override if the automatic<br>
> allocation doesn't match their needs or in the case that they want to use<br>
> external LB).<br>
><br>
> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1482399" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1482399</a><br>
> [2] <a href="https://review.openstack.org/230943" rel="noreferrer" target="_blank">https://review.openstack.org/230943</a><br>
><br>
> So, I have the following proposal for now:<br>
> Add new url (e.g. /clusters/<cluster_id>/network_configuration/vips/ ), use<br>
> GET<br>
> to query current VIPs info, use PUT to change VIPs addresses (set them<br>
> manually<br>
> or request to allocate them automatically).<br>
> Now VIPs have the following format in API requests data:<br>
> vips: [<br>
>     {<br>
>         'network_role': 'management',<br>
>         'namespace': 'haproxy',<br>
>         'ipaddr': '10.10.10.10',<br>
>         'node_roles': ['controller']<br>
>     },...<br>
> ]<br>
> So, 'ipaddr' field can be set to any (almost any) user-defined value or to<br>
> None (null in YAML).<br>
> When it is set to None, IP address will be allocated automatically. When the<br>
> user runs GET<br>
> request for the first time, all 'ipaddr' fields are equal to None. So, user<br>
> can set some (or all)<br>
> of them to desired values and run PUT. When the GET is run after PUT, all<br>
> addresses will be<br>
> filled with values. User can reset some of them to None or change to other<br>
> IP when required.<br>
> So, addresses will be re-allocated on the next PUT requests.<br>
> If address given by user overlaps with some of the allocated IPs, PUT<br>
> request will be rejected.<br>
> There is a question, what to do when the given address overlaps with the<br>
> network from another<br>
> environment? overlaps with the network of current environment which does not<br>
> match the<br>
> network role of the VIP?<br>
> My opinion that those should pass with a warning message.<br>
><br>
> Please share your proposals and comments on this,<br>
><br>
> Thanks,<br>
><br>
><br>
> Aleksey Kasatkin<br>
><br>
><br>
</div></div>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>