Roman, > This behavior is actually described in [1]. Should we allocate > VIPs on network check as well?
No, we shouldn't. We should check whether it's enough IPs for nodes / VIPs with current network configuration, but no more. - igor On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Andrew, > >> but the problem lies that VIP's need to already be allocated. > > Why? Fuel doesn't use them on this stage. > > >> They need to be allocated on network update, or when a node role requiring >> one is added to the environment. > > It looks like either you or me misunderstood something. AFAIK, node > role itself has nothing in common with VIPs. It doesn't require any of > them. > > Currently VIPs are requested by network roles, and network roles are > the same for all nodes (except Network Templating case). Network roles > are assigned on network, and if VIP is required for network role it > will be allocated in the assigned network. > > So basically, it requires a huge effort to redesign our allocation > system to achieve what you want, because: > > * Each time you reassign network role, the corresponding VIP should be > re-allocated in the database either. > * Each time you enable/disable plugins, the VIPs should be > re-allocated, because plugins may export network roles. > * Each time you add new node to cluster, the VIPs should be > re-allocated, because with new node you simply may run out of free > IPs. And, btw, should we assign IP on added nodes here? Or maybe > postpone to serialization step? > > Well, Andrew, I believe we don't have enough resources to implement > your proposal. Moreover, the proposed approach requires a lot of > discussions and design meetings. And it definitely should be > implemented in scope of some blueprint, not a bugfix. > > >> Not knowing the address until serialization for deployment is too late. > > Once again - why? I agree, perhaps it would be useful, but there's no > strict requirement on this and we should resolve our issues > step-by-step. See my response above. > > >> No, Again, this is too late. > > Too late for what? > > > - Igor > > On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko <m...@romcheg.me> wrote: >> My concern here is that there is also a Network check feature that according >> to its name should check things like whether or not there’s enough IP >> addresses in all ranges in a network. The problem is that it may be run at >> any time, even when VIPs are not yet allocated. From a user-side the >> workflow may look a little wrong: >> >> 1. Check network => get "Everything is fine" >> 2. Right after that press Apply Changes => get "Network configuration is >> bad" >> >> This behavior is actually described in [1]. Should we allocate VIPs on >> network check as well? >> >> >> 1. https://bugs.launchpad.net/fuel/+bug/1487996 >> >> >> - romcheg >> >> >>> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky <ikalnit...@mirantis.com> >>> написав(ла): >>> >>> 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
