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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> Folks, we should resurrect this thread and find a consensus. >>> >>> 1 вер. 2015 р. о 15:00 Andrey Danin <[email protected]> написав(ла): >>> >>> >>> +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 <[email protected]> >>> 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 <[email protected]> >>>> 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: >>>> [email protected]?subject:unsubscribe >>>> <http://[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://[email protected]/?subject:unsubscribe> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> Andrey Danin >>> [email protected] >>> skype: gcon.monolake >>> >>> __________________________________________________________________________ >>> 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 >>> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> __________________________________________________________________________ >> 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
