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 <m...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
