Hide Forgot
Created attachment 1212706 [details] "Some flavors not meeting minimum image requirements have been disabled" is showing under the flavor selection Description of problem: Can not choose flavor in dashboard if glance.min_disk > flavor.disk Version-Release number of selected component (if applicable): python-django-horizon-8.0.1-6.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Create a flavor with Root Disk (GB) = 0 2. Create an image with Minimum Disk (GB) = 1 3. Launch instance and select the image we created in step2. 4. We can not select the flavor we created in step 1 and it is showing grey. Actual results: Horizon is making an unnecessary check. https://github.com/openstack/horizon/blob/stable/liberty/horizon/static/horizon/js/horizon.quota.js#L150 https://github.com/openstack/horizon/blob/stable/liberty/horizon/static/horizon/js/horizon.quota.js#L86 https://github.com/openstack/horizon/blob/stable/liberty/horizon/static/horizon/js/horizon.quota.js#L78 Expected results: We should be able to launch instance even though glance.min_disk > flavor.disk. Additional info: There is no problem if we launch instance from command line.
This is expected behavior. See bz#1172612.
We set "0" to flavor root disk. How does instance handle this setting? OpenStack Docs says; http://docs.openstack.org/admin-guide/compute-flavors.html The "0" size is a special case which uses the native base image size as the size of the ephemeral root volume. It seems that the flavor which have "0" root disk would not be selected on horizon forever.
Hi Junko, Yes your finding is correct. Let me reopen the bugzilla and show some details. @Radomir would you please have a look at this ? Sorry for an unclear initial description . In /usr/lib/python2.7/site-packages/nova/compute/api.py 736 # NOTE(johannes): root_gb is allowed to be 0 for legacy reasons 737 # since libvirt interpreted the value differently than other 738 # drivers. A value of 0 means don't check size. 744 if image_min_disk > dest_size: 745 raise exception.FlavorDiskSmallerThanMinDisk( 746 flavor_size=dest_size, image_min_disk=image_min_disk) We can see that if the root_gb is 0, then nova will not check the disk size. But Horizon seems to be still checking even though the root_gb is 0. Horizon should take care of this situation when root_gb == 0. Best Regards, Chen
So in line 739 we will skip the check if root_gb is 0. Horizon should be consistent with nova to some extent. In /usr/lib/python2.7/site-packages/nova/compute/api.py 736 # NOTE(johannes): root_gb is allowed to be 0 for legacy reasons 737 # since libvirt interpreted the value differently than other 738 # drivers. A value of 0 means don't check size. 739 if dest_size != 0: 740 if image_size > dest_size: 741 raise exception.FlavorDiskSmallerThanImage( 742 flavor_size=dest_size, image_size=image_size) 743 744 if image_min_disk > dest_size: 745 raise exception.FlavorDiskSmallerThanMinDisk( 746 flavor_size=dest_size, image_min_disk=image_min_disk) Best Regards, Chen
I see now, that's looks like a bug indeed, thank you very much for reporting it. I'm sorry for jumping to conclusions.
Hi Radomir, No worries at all. Sorry for my unclear description. Best Regards, Chen
Hi Radomir, Sorry for the interrupt. It would be appreciated if I can get any progress on the fix. Thank you very much ! Best Regards, Chen
Hi Radomir, Thank you for your update. I'm increasing the priority because the customer is keen on the fix of this bug. Best Regards, Chen
Hi Anandeep, Thank you for your help on this bugzilla. If you got any progress about this bug please let me know. Best Regards, Chen
Assigned, on backlog but nothing to report yet.
Hi, Do we have any news about the progress? Best Regards, Chen
Hi Chen, There is not currently any further big update on this, however, we are aware of the bug and we will be working on it during the next sprint and have a further update on progress soon. Thanks, Beth
I can verify that this now works as expected: I can select flavors with 0GB disks when an image with min disk 2GB is selected.
Hi Beth, Radomir, Thank you for your great help. I can see the function has been verified by Radomir. Is there any news about the downstream release date or hotfix if it's hard to make it before the deadline ? Best Regards, Chen
Hi Chen, This bug has been fixed and verified for OSPs 8, 9 and 10. We are working to have it delivered in OSP8 next week. Thanks, Beth
This bug has been fixed and merged upstream for the current release and it will be delivered in OSP8 this week.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1471