<div dir="ltr">Folks, you are welcome to review a spec: <a href="https://review.openstack.org/254796">https://review.openstack.org/254796</a><br><br></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 Fri, Nov 6, 2015 at 6:03 PM, 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>Mike, Vladimir,<br><br></div>Yes, <br><span>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).<br></span>2. We should allow to leave fields '<span>network_role', '</span><span>node_roles', '</span><span>namespace' empty. So, validation should be changed.<br></span></div><span></span><br></div>So, answer here<span class=""><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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></blockquote></span><div>should be "Any allocated IP is accessible via these handlers", so URLs can be changed to <br><div><span>/clusters/<cluster_id>/network_configuration/ips/</span></div><span>/clusters/<cluster_id>/network_configuration/ips/<id>/ </span><br></div><div>Nodes IPs maybe the different story though.<br></div><div><br></div><div>Alex,<br><br><span>'node_roles' determines in what node group to allocate IP. So, it will be group with controller nodes for our base VIPs <br>(they all have </span><span><span></span><span>node_roles</span>=['controller'] which is default setting).<br></span></div><div><span>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<br>for this network role (with </span>'<span>network_role'='ceph</span><span><span>/vip</span>' and </span><span>'</span><span>node_roles'=['ceph/osd']). This VIP will be allocated <br>in the network that '</span><span><span>ceph</span><span><span>/vip</span></span>' is mapped to and in the node group where ceph nodes are located. ceph nodes cannot be located <br>in more than one node group then (as VIP cannot migrate between </span><span><span>node group</span>s now).<span class="HOEnZb"><font color="#888888"><br></font></span></span></div><span class="HOEnZb"><font color="#888888"><div><div><span><br><br></span></div></div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@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">+1 to Mike<div><br></div><div>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. </div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@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">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.<div>More specifically, can we reserve IP address(-es) with some codename, and use it later?</div><div>12.12.12.12 - my-shared-ip</div><div>240.0.0.2 - my-multicast</div><div>and then use them in puppet / whatever deployment code by $my-shared-ip, $my-multicast?</div><div><br></div><div>Thanks,</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin <<a href="mailto:akasatkin@mirantis.com" target="_blank">akasatkin@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Folks,<br><br></div>Here is a resume of our recent discussion:<br><br><div>1. Add new URLs for processing VIPs:<br></div><div><br></div><div><span>/clusters/<cluster_id>/network_configuration/vips/ (GET)</span></div><div><span>/clusters/<cluster_id>/network_configuration/vips/<id>/ (GET, PUT)</span></div><div><br></div><div>where <id> is the id in ip_addrs table.<br></div><div>So, user can get all VIPS, get one VIP by id, change parameters (IP address) for one VIP by its id.<br></div><div>More possibilities can be added later.<br></div><div><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> Add current VIP meta into ip_addrs table.<br><br></span></div><div><span>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>(relation)</span><br></div><div><br>Q. We could replace vip_type (it contains VIP name now) with vip_info.<br></div><div><span><br>3. Allocate VIPs on cluster creation and seek VIPs at all network changes.</span></div><div><br></div><div>So, VIPs will be checked (via network roles descriptions) and re-allocated in ip_addrs table <br>at these points:<br></div><div>a. create cluster<br></div><div>b. modify networks configuration<br></div><div>c. modify one network<br></div><div>d. modify network template<br></div><div>e. change nodes set for cluster<br></div><div>f. change node roles set on nodes<br></div><div>g. modify cluster attributes (change set of plugins)<br></div><div>h. modify release<br></div><div><br></div><div><span>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><span> {</span></div><div><span> 'name': 'management'<br></span></div><div><span> 'network_role': 'mgmt/vip',</span></div><div><span> 'namespace': 'haproxy',</span></div><span> 'node_roles': ['controller'],</span><div><span> 'alias': 'management_vip',<br> 'manual': True,<br></span></div><span> }<br><br>Example of current VIP description:<br><a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207</a><br><br></span></div><div><span>Nailgun will re-allocate VIP address if 'manual' == False.<br></span></div><div><br></div><div>5. Q. <span>what to do when the given address overlaps with the network from another</span></div></div><div dir="ltr"><div><div><span>environment? overlaps with the network of current environment which does not match the</span></div><div><span>network role of the VIP?</span></div></div></div><div dir="ltr"><div></div><div><br><span>Use '--force' parameter to change it. PUT will fail otherwise.<br><br><br></span></div><div><span>Guys, please review this and share your comments here,<br><br></span></div><div><span>Thanks,<br></span></div><div><br><br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div></div><div class="gmail_extra">
<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><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><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><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><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><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><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>
<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>
__________________________________________________________________________<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></div></div><span><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>
</font></span><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br><a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904" target="_blank">+7 (495) 640-49-04</a><br><a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968" target="_blank">+7 (926) 702-39-68</a><br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>
<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>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>