<div dir="ltr"><div><div><div>Igor, <br><br>> For VIP allocation we should use POST request. It's ok to use PUT for setting (changing) IP address.<br><br></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><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><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?<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></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?<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></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><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><div>It is now done for network verification that it can pass with warning message.<br></div><div>But I like your proposal better.<br><br><span class="im">> overlaps with the network of current environment which does not<br>
> match the network role of the VIP?</span><br></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 class="gmail_signature"><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div>
<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 class=""><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 class=""><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 class=""><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 class=""><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 class=""><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 class="">> 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 class=""><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 class="h5"><br>
On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin <<a href="mailto:akasatkin@mirantis.com">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>