Then we should close [1] as invalid, shoudn’t we? > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky <[email protected]> написав(ла): > > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>>> написав(ла): >>>> >>>> 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 <[email protected]> >>>> 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: [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
