Open Stack

> Random choices aren't good IMHO, let's use defaults.

What if neither of node is in default group? Still use default group?
And prey that some third-party plugin will handle this case properly?

AFAIU, default nodegroup is slightly artificial thing. There's no such
thing like *default* nodegroup. Nodes may be in either group A or
group B. No defaults. Default is just pre-created nodegroup and that's
it, so there's nothing special in it. That's why I think it's bad idea
to remove limitation just because someone somewhere with manual hacks
and workaround *may* deploy controllers in different multi-racks. We
don't support load-balancing for nodes in different racks out-of-box.
Let's proceed with it for 8.0, and make a proper fix in 9.0.

On Fri, Jan 15, 2016 at 11:50 AM, Bogdan Dobrelya
<bdobrelia at mirantis.com> wrote:
> On 15.01.2016 10:19, Aleksandr Didenko wrote:
>> Hi,
>>
>> We need to come up with some solution for a problem with VIP generation
>> (auto allocation), see the original bug [0].
>>
>> The main problem here is: how do we know what exactly IPs to auto
>> allocate for VIPs when needed roles are in different nodegroups (i.e. in
>> different IP networks)?
>> For example 'public_vip' for 'controller' roles.
>>
>> Currently we have two possible solutions.
>>
>> 1) Fail early in pre-deployment check (when user hit "Deploy changes")
>> with error about inability to auto allocate VIP for nodes in different
>> nodegroups (racks). So in order to run deploy user has to put all roles
>> with the same VIPs in the same nodegroups (for example: all controllers
>> in the same nodegroup).
>>
>> Pros:
>>
>>   * VIPs are always correct, they are from the same network as nodes
>>     that are going to use them, thus user simply can't configure invalid
>>     VIPs for cluster and break deployment
>>
>> Cons:
>>
>>   * hardcoded limitation that is impossible to bypass, does not allow to
>>     spread roles with VIPs across multiple racks even if it's properly
>>     handled by Fuel Plugin, i.e. made so by design
>
> That'd be no good at all.
>
>>
>>
>> 2) Allow to move roles that use VIPs into different nodegroups, auto
>> allocate VIPs from "default" nodegroup and send an alert/notification to
>> user that such configuration may not work and it's up to user how to
>> proceed (either fix config or deploy at his/her own risk).
>
> It seems we have not much choice then, but use the option 2
>
>>
>> Pros:
>>
>>   * relatively simple solution
>>
>>   * impossible to break VIP serialization because in the worst case we
>>     allocate VIPs from default nodegroup
>>
>> Cons:
>>
>>   * user can deploy invalid environment that will fail during deployment
>>     or will not operate properly (for example when public_vip is not
>>     able to migrate to controller from different rack)
>>
>>   * which nodegroup to choose to allocate VIPs? default nodegroup?
>>     random pick? in case of random pick troubleshooting may become
>>     problematic
>
> Random choices aren't good IMHO, let's use defaults.
>
>>
>>   * waste of IPs - IP address from the network range will be implicitly
>>     allocated and marked as used, even it's not used by deployment
>>     (plugin uses own ones)
>>
>>
>> *Please also note that this solution is needed for 8.0 only.*In 9.0 we
>> have new feature for manual VIPs allocation [1]. So in 9.0, if we can't
>> auto allocate VIPs for some cluster configuration, we can simply ask
>> user to manually set those problem VIPs or move roles to the same
>> network node group (rack).
>>
>> So, guys, please feel free to share your thoughts on this matter. Any
>> input is greatly appreciated.
>>
>> Regards,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1524320
>> [1] https://blueprints.launchpad.net/fuel/+spec/allow-any-vip
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> 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