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
