<div dir="ltr"><div><div><div>Hi,<br><br></div>btw, we should also take into account the possibility to share networks in Fuel-8.0. So if cluster is configured with shared public and management networks then moving controllers into different network node groups (racks) is fine and it will work out of the box [0] and we should not forbid such configuration.<br><br></div>Regards,<br></div>Alex<br><br>[0] <a href="https://bugs.launchpad.net/fuel/+bug/1524320/comments/12">https://bugs.launchpad.net/fuel/+bug/1524320/comments/12</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 9:42 AM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@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><div><div><div>Hi,<br><br></div>I would also prefer second solution. The only real downside of it is the possibility to configure invalid cluster (for instance configure default "controller" roles in different racks). But such invalid configuration is possible only under some conditions:<br></div>- User should configure multi-rack environment (network node groups). I'd say it's rather advanced Fuel usage and user most likely will follow our documentation, so we can describe possible problems in the documentation.<br></div>- User should ignore notifications about possible problems from Fuel. I must say that this is quite possible when using CLI, because notifications should be checked manually in this case.<br><br></div>Solution #1 is much safer, of course. But for me it looks like "let's forbid as much as we can just to avoid any risks". I prefer to give Fuel users a choice here which is possible only in second solution.<span class=""><br><br>> What if neither of node is in default group? Still use default group?<br>> And prey that some third-party plugin will handle this case properly?<br>
<br></span></div><div>No, let's put a warning for user. I don't think that forbidding is the proper way of handling such situations. Especially when we're not going to forbid such setup in 9.0.<br></div><span class=""><div><br>> Default is just pre-created nodegroup and that's it, so there's nothing special in it.<br><br></div></span><div>Not quite. Default groups is the group where Fuel node is connected to.<span class=""><br><br>> We don't support load-balancing for nodes in different racks out-of-box.<br><br></span></div><div>True. But we're going block deployment of roles that share VIP (created from plugin, for instance) even when no load-balancing is involved at all - just to be safe.<br></div><div><br></div>Regards,<br></div>Alex<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 10:50 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 15.01.2016 10:19, Aleksandr Didenko wrote:<br>
> Hi,<br>
><br>
> We need to come up with some solution for a problem with VIP generation<br>
> (auto allocation), see the original bug [0].<br>
><br>
> The main problem here is: how do we know what exactly IPs to auto<br>
> allocate for VIPs when needed roles are in different nodegroups (i.e. in<br>
> different IP networks)?<br>
> For example 'public_vip' for 'controller' roles.<br>
><br>
> Currently we have two possible solutions.<br>
><br>
> 1) Fail early in pre-deployment check (when user hit "Deploy changes")<br>
> with error about inability to auto allocate VIP for nodes in different<br>
> nodegroups (racks). So in order to run deploy user has to put all roles<br>
> with the same VIPs in the same nodegroups (for example: all controllers<br>
> in the same nodegroup).<br>
><br>
> Pros:<br>
><br>
</span>>   * VIPs are always correct, they are from the same network as nodes<br>
<span>>     that are going to use them, thus user simply can't configure invalid<br>
>     VIPs for cluster and break deployment<br>
><br>
> Cons:<br>
><br>
</span>>   * hardcoded limitation that is impossible to bypass, does not allow to<br>
<span>>     spread roles with VIPs across multiple racks even if it's properly<br>
>     handled by Fuel Plugin, i.e. made so by design<br>
<br>
</span>That'd be no good at all.<br>
<span><br>
><br>
><br>
> 2) Allow to move roles that use VIPs into different nodegroups, auto<br>
> allocate VIPs from "default" nodegroup and send an alert/notification to<br>
> user that such configuration may not work and it's up to user how to<br>
> proceed (either fix config or deploy at his/her own risk).<br>
<br>
</span>It seems we have not much choice then, but use the option 2<br>
<br>
><br>
> Pros:<br>
><br>
>   * relatively simple solution<br>
><br>
>   * impossible to break VIP serialization because in the worst case we<br>
<span>>     allocate VIPs from default nodegroup<br>
><br>
> Cons:<br>
><br>
</span>>   * user can deploy invalid environment that will fail during deployment<br>
<span>>     or will not operate properly (for example when public_vip is not<br>
>     able to migrate to controller from different rack)<br>
><br>
</span>>   * which nodegroup to choose to allocate VIPs? default nodegroup?<br>
<span>>     random pick? in case of random pick troubleshooting may become<br>
>     problematic<br>
<br>
</span>Random choices aren't good IMHO, let's use defaults.<br>
<br>
><br>
>   * waste of IPs - IP address from the network range will be implicitly<br>
<span>>     allocated and marked as used, even it's not used by deployment<br>
>     (plugin uses own ones)<br>
><br>
><br>
</span>> *Please also note that this solution is needed for 8.0 only.*In 9.0 we<br>
<span>> have new feature for manual VIPs allocation [1]. So in 9.0, if we can't<br>
> auto allocate VIPs for some cluster configuration, we can simply ask<br>
> user to manually set those problem VIPs or move roles to the same<br>
> network node group (rack).<br>
><br>
> So, guys, please feel free to share your thoughts on this matter. Any<br>
> input is greatly appreciated.<br>
><br>
> Regards,<br>
> Alex<br>
><br>
> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1524320" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1524320</a><br>
> [1] <a href="https://blueprints.launchpad.net/fuel/+spec/allow-any-vip" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/allow-any-vip</a><br>
><br>
><br>
><br>
</span>> __________________________________________________________________________<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>
<span><font color="#888888"><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<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>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>