Open Stack

It's not about Public networks only. There can be the same problem with
other networks as well.
It's required to check all the networks (across all node groups).
But it is done just for Public network now (and VIPs for plugins are not
taken into account).


Aleksey Kasatkin


On Fri, Nov 20, 2015 at 12:04 AM, Andrew Woodward <xarses at gmail.com> wrote:

> The high value of the bug here reflects that the error message is wrong.
> From a UX side we could maybe even justify this as Critical. The error
> message must reflect the correct quantity of addresses required.
>
>
> On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko <me at romcheg.me> wrote:
>
>> Folks, we should resurrect this thread and find a consensus.
>>
>> 1 вер. 2015 р. о 15:00 Andrey Danin <adanin at mirantis.com> написав(ла):
>>
>>
>> +1 to Igor.
>>
>> It's definitely not a High bug. The biggest problem I see here is a
>> confusing error message with a wrong number of required IPs. AFAIU we
>> cannot fix it easily now so let's postpone it to 8.0 but change a message
>> itself [0] in 7.0.
>>
>> We managed to create an error that returns '7', when there are 8
> available, but 9 are required, at some level we knew that we came up short
> or we'd just have some lower level error caught here.
>
>>
>> [0]
>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>>
>> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
>> wrote:
>>
>>> Hello,
>>>
>>> My 5 cents on it.
>>>
>>> I don't think it's really a High or Critical bug for 7.0. If there's
>>> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
>>> actually Ok, it may fail by different reason without starting actual
>>> deployment (sending message to Astute).
>>>
>>> But I agree it's kinda strange that we don't check IPs during network
>>> verification step. The good fix in my opinion is to move this check
>>> into network checker (perhaps keep it here either), but that
>>> definitely shouldn't be done in 7.0.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko <me at romcheg.me>
>>> wrote:
>>> > Hi folks!
>>> >
>>> > Recently a problem that network check does not tell whether there’s
>>> enough IP addresses in a public network [1] was reported. That check is
>>> performed by CheckBeforeDeployment task, but there is two problems that
>>> happen because this verification is done that late:
>>> >
>>> >  - A deployment fails, if there’s not enough addresses in specified
>>> ranges
>>> >  - If a user wants to get network configuration they will get an error
>>> >
>>> > The solution for this problems seems to be easy and a straightforward
>>> patch [2] was proposed. However, there is a hidden problem which is that
>>> patch does not address which is that installed plugins may reserve VIPs for
>>> their needs. The issue is that they do it just before deployment and so
>>> it’s not possible to get those reservations when a user wants to check
>>> their network set up.
>>> >
>>> > The important issue we have to address here is that network
>>> configuration generator will fail, if specified ranges don’t fit all VIPs.
>>> There were several proposals to fix that, I’d like to highlight two of them:
>>> >
>>> >  a) Allow VIPs to not have an IP address assigned, if network config
>>> generator works for API output.
>>> >      That will prevent GET requests from failure, but since IP
>>> addresses for VIPs are required, generator will have to fail, if it
>>> generates a configuration for the orchestrator.
>>> >  b) Add a release note that users have to calculate IP addresses
>>> manually and put sane ranges in order to not shoot their own legs. Then
>>> it’s also possible to change network verification output to remind users to
>>> check the ranges before starting a deployment.
>>> >
>>> > In my opinion we cannot follow (a) because it only masks a problem
>>> instead of providing a fix. Also it requires to change the API which is not
>>> a good thing to do after the SCF. If we choose (b), then we can work on a
>>> firm solution in 8.0 and fix the problem for real.
>>> >
>>> >
>>> > P. S. We can still merge [2], because it checks, if IP ranges can at
>>> least fit the basic configuration. If you agree, I will update it soon.
>>> >
>>> > [1] https://bugs.launchpad.net/fuel/+bug/1487996
>>> > [2] https://review.openstack.org/#/c/217267/
>>> >
>>> >
>>> >
>>> > - romcheg
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __________________________________________________________________________
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Andrey Danin
>> adanin at mirantis.com
>> skype: gcon.monolake
>> __________________________________________________________________________
>> 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
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151120/580f0ea5/attachment.html>