Open Stack

We have more generic ticket: https://bugs.launchpad.net/fuel/+bug/1354803
and corresponding CR: https://review.openstack.org/#/c/245941/

Aleksey Kasatkin


On Fri, Nov 20, 2015 at 11:24 AM, Aleksey Kasatkin <akasatkin at mirantis.com>
wrote:

> 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/8e4f31c3/attachment.html>