+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.
[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://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 > -- 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
