Only volume-backed servers are allowed for flavors with zero disk.

[Patrick Oberdorf]

Hello,

we upgraded to latest OpenStack release from queens to stein. After the upgrade we expect some problem with resize of instances. We use only volume-backed instances based on cinder-ceph. If we want to resize the instance we encounter: Only volume-backed servers are allowed for flavors with zero disk. (HTTP 403)

All our Flavors have 0 disk and the resize worked in queens. Do we miss something here?

[Takashi Natsume (natsume-takashi)]

Related changes were as follows:

Add policy rule to block image-backed servers with 0 root disk flavor
https://review.opendev.org/#/c/561284/

Default zero disk flavor to RULE_ADMIN_API in Stein
https://review.opendev.org/#/c/603910/

The default rule of "os_compute_api:servers:create:zero_disk_flavor" has been changed to "rule:admin_api" since stein.
But "rule:admin_or_owner" can be set for it in the nova policy file.

[Patrick Oberdorf (obi12341)]

Thanks for your answer. This behavior still looks buggy to me. I am able to create new instances with a flavor and 0 disk but if I want to resize it, it get this error. Is it intended to work like that?

[Matt Riedemann (mriedem)]

Have you configured the "os_compute_api:servers:create:zero_disk_flavor" policy rule like Takashi noted in comment 2? I want to be clear about the recreate scenario on Stein - can you describe that?

I'm assuming something like, you have two flavors, flavor1 and flavor2, both with disk=0.

1. create volume-backed server with flavor1
2. resize server with flavor2

You're saying you get an error in that case?

I know there were some changes in Stein with the resize flow and the compute API method "_validate_flavor_image_nostatus" so maybe something regressed there. It should be pretty simple to recreate in a functional test so I'll try that.

[Matt Riedemann (mriedem)]

Just a clarification, is the problem that you enabled "os_compute_api:servers:create:zero_disk_flavor" for non-admins and they are creating servers that are NOT volume-backed and then trying to resize those fails? You said you only use volume-backed instances so I'm confused about the recreate scenario.

[Matt Riedemann (mriedem)]

OK I think https://review.opendev.org/#/c/620706/ is the regression because of this:

https://review.opendev.org/#/c/620706/32/nova/compute/api.py@3598

The resize flow passes root_bdm=None to _validate_flavor_image_nostatus which makes it take this else block:

https://review.opendev.org/#/c/620706/32/nova/compute/api.py@585

and then we fail here:

https://review.opendev.org/#/c/620706/32/nova/compute/api.py@642

When https://review.opendev.org/#/c/561284/ was written that validation code wasn't called during resize.

That code had introduced regression bug 1825020 which was fixed in Stein here:

https://review.opendev.org/#/c/656666/

It looks like that should fix your problem and is in the 19.0.1 release. Which release are you using for Stein?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/672067

[Matt Riedemann (mriedem)]

I wrote this functional test https://review.opendev.org/#/c/672067/ and things seem to be working OK, but even if I revert https://review.opendev.org/#/c/656666/ the test passes so I'm not sure the test is very useful, but I'm not sure I have the recreate scenario figured out for your bug (I'd need those details). Given the code has changed for volume-backed resize where this would fail, I have marked this as a duplicate of bug 1825020. Please let me know if I've missed something.

[Patrick Oberdorf (obi12341)]

Hey,

I can confirm after upgrading 19.0.1 (we had 19.0.0 before) everything worked as expected. Thanks for your effort :) This can be closed.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.opendev.org/672067
Reason: The bug reporter confirmed that I91c9c1e88afa035c757f692c78ad72d69cc3c431 resolved their issue in Stein 19.0.1 and given this doesn't really recreate the failure anyway (because the test is using admin creds which pass the policy check on volume-backed resize) it's not a very useful test at this point.