Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/41ad71cf/attachment.html>