Open Stack

Then we should close [1] as invalid, shoudn’t we?

> 20 жовт. 2015 р. о 15:55 Igor Kalnitsky <ikalnitsky at mirantis.com> написав(ла):
> 
> 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 <ikalnitsky at 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 <me at 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 <ikalnitsky at 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 <me at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/297a827f/attachment.pgp>