> 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 <bdobre...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
