Aleksey, Thank you for input.
> We have a ticket for 8.0 to give an ability to set arbitrary addresses for > VIPs That shouldn't affect proposed approach. The main idea is to return *allocated VIPs* but *do not allocate* them implicitly. > we also need to provide an ability to run CheckBeforeDeployment task > separately That's another story. Let's keep close to main subject, and a bunch of issues mentioned by Roman, Thanks, Igor On Mon, Oct 19, 2015 at 8:05 PM, Aleksey Kasatkin <akasat...@mirantis.com> wrote: > Hi! > > I mostly agree with Igor, GET request should not produce changes (i.e. > allocate VIPs). > >> VIP allocation should be performed when we run deployment. > > I want to give an explanation here. We have a ticket for 8.0 to give an > ability to set arbitrary addresses for VIPs. So, at least some of VIPs can > be set via API calls. And auto-allocation of addresses for VIPs should be > done just before deployment. The only concern here, whether we need a VIP > for net-checker. We could allocate VIPs on net-checker request then also (it > is PUT request). > > AFAIC, we also need to provide an ability to run CheckBeforeDeployment task > separately (only within ApplyChanges for now). It will help the user to > diagnose different problems. It seems to be a subject for another > discussion/ticket though. > > Thanks, > > > > > Aleksey Kasatkin > > > On Mon, Oct 19, 2015 at 11:28 AM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hi Roman, >> >> > Not assign addresses to VIPs is a network configuration is being >> > serialized for API output. >> >> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP. >> So we can keep only *public* VIP, and do not assign / show others. >> >> > Check number of IP addresses wherever it is possible to "spoil" network >> > configuration: when a role get’s assigned to a node, when network >> > changes or network templates are applied. >> >> It won't work that way. What if you enable plugin when all roles are >> assigned? What if you change networks, and now it's not enough IPs? Or >> what if enable plugin that requires 5 VIPs in public network by >> default, and it's not enough. But by using network templates you >> assign this netrole to management network? >> >> From what I can say the proposed approach requires to put checks >> here-and-there around the code. Let's do not overcomplicate things >> without real need. >> >> So let me share my thoughts regarding this issue. >> >> * We shouldn't *allocate* VIPs when we make GET request on network >> configuration handler. It should return only *already allocated* VIPs >> and no more. >> * VIP allocation should be performed when we run deployment. >> * Before deployment checks should fail, if there's not enough VIPs or >> other resources. So users fix them, and try again. >> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and >> it's safe to return allocated VIPs on that stage. >> >> So what do you think guys? >> >> Thanks, >> Igor >> >> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <m...@romcheg.me> >> wrote: >> > Hi folks! >> > >> > I’ve been discussing several bugs [1-3] with some folks and noticed that >> > they share the same root cause which is that network serialization fails, >> > if >> > there’s not enough IP addresses in all available ranges of one of the >> > available networks to assign them to all VIPs. There are several possible >> > solutions for this issue: >> > >> > a. Not assign addresses to VIPs is a network configuration is being >> > serialized for API output. >> > A lot of external tools and modules, i. e., OSTF, rely on that >> > information so this relatively small change in Nailgun will require big >> > cross-components changes. Therefore this change can only be done as a >> > feature but it seems to be the way this issue must be fixed. >> > >> > b. Leave some VIPs without IP addresses >> > If network configuration is generated for API output it is possible to >> > leave some VIPs without IP addresses assigned. This will only create more >> > mess around Nailgun and bring more issues that it will resolve. >> > >> > c. Check number of IP addresses wherever it is possible to "spoil" >> > network configuration: when a role get’s assigned to a node, when network >> > changes or network templates are applied. >> > >> > >> > The proposal is to follow [c] as a fast solution and file a blueprint >> > for [a]. Opinions? >> > >> > >> > 1 https://bugs.launchpad.net/fuel/+bug/1487996 >> > 2 https://bugs.launchpad.net/fuel/+bug/1500394 >> > 3 https://bugs.launchpad.net/fuel/+bug/1504572 >> > >> > >> > - romcheg >> > >> > >> > __________________________________________________________________________ >> > 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 > > > > __________________________________________________________________________ > 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