| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-06 | |||
| 10:51:20 | sean-k-mooney | bauzas: that is intentional | |
| 10:51:32 | whoami-rajat | sean-k-mooney, ack, will take a look at the osc patch | |
| 10:51:33 | bauzas | sean-k-mooney: then the spec was telling other thing | |
| 10:51:44 | bauzas | sean-k-mooney: the spec will telling you were able to opt-out | |
| 10:51:46 | sean-k-mooney | bauzas: then the spec is wrong | |
| 10:52:06 | bauzas | sean-k-mooney: see https://review.opendev.org/c/openstack/nova-specs/+/840155/5/specs/zed/approved/volume-backed-server-rebuild.rst#143 | |
| 10:52:36 | bauzas | we were keeping the original behavior with 2.93 if the user was passing a parameter | |
| 10:52:53 | bauzas | actually, no | |
| 10:53:05 | sean-k-mooney | no that is discribibg the osc change | |
| 10:53:10 | bauzas | the spec was saying that 'reimage is opt-in with 2.93' | |
| 10:53:16 | sean-k-mooney | no | |
| 10:53:22 | sean-k-mooney | that is client side only | |
| 10:53:28 | bauzas | and here we're discussing of "no reimage is opt-out with 2.93' | |
| 10:53:32 | sean-k-mooney | the nova api will not provde a way to opt in or out | |
| 10:53:44 | sean-k-mooney | other then the micorverions | |
| 10:53:45 | bauzas | oh you're right | |
| 10:53:52 | bauzas | "on the client side" | |
| 10:53:55 | sean-k-mooney | yes | |
| 10:54:00 | bauzas | so | |
| 10:54:05 | bauzas | 2.93 makes it default | |
| 10:54:24 | bauzas | and users can say no just by a client parameter | |
| 10:54:35 | sean-k-mooney | no | |
| 10:54:46 | bauzas | then clarify the spec | |
| 10:54:55 | sean-k-mooney | 2.93 makes it unconditional because we wanted rebuild to mean rebuild | |
| 10:55:02 | bauzas | which I understand | |
| 10:55:06 | sean-k-mooney | if you want the old behaivor you use the old microversion | |
| 10:55:14 | bauzas | yes | |
| 10:55:20 | sean-k-mooney | the client check was ment to prevent the request if you did not pass the parmater | |
| 10:55:28 | bauzas | so I don't see a need for an extra param on the client | |
| 10:55:31 | sean-k-mooney | not downgrade the microverios | |
| 10:55:39 | bauzas | ok, then I understand | |
| 10:55:50 | bauzas | you need to say "yes, I understand I'll reimage" | |
| 10:55:55 | sean-k-mooney | exactly | |
| 10:55:57 | whoami-rajat | sean-k-mooney, bauzas , as i see, the novaclient changes are not even needed i guess, just bumping the version to 2.93 should be enough right? | |
| 10:56:14 | sean-k-mooney | whoami-rajat: yep just bumping the max version | |
| 10:56:19 | sean-k-mooney | the rest is not needed | |
| 10:56:24 | bauzas | whoami-rajat: correct | |
| 10:56:27 | whoami-rajat | ack, will update | |
| 10:56:48 | bauzas | well | |
| 10:56:49 | bauzas | sec | |
| 10:57:02 | bauzas | sean-k-mooney: we also need a param on the python bindings | |
| 10:57:06 | sean-k-mooney | on the osc change you need to check when the micorversion is 2.93 or higher that --remiage is pased if its a bfv instance | |
| 10:57:10 | bauzas | like, | |
| 10:57:25 | sean-k-mooney | bauzas: we dont as the python bindigns are not ment to do this check | |
| 10:57:27 | bauzas | "I want explain I know I'll reimage" with my python script | |
| 10:57:33 | sean-k-mooney | nope | |
| 10:57:38 | sean-k-mooney | that is not desireable | |
| 10:57:56 | bauzas | then we need to clarify this paragraph on the spec, this is confusing | |
| 10:58:10 | sean-k-mooney | ack we can do that | |
| 10:58:23 | sean-k-mooney | the python bindings should have the same behavior as the api | |
| 10:58:24 | bauzas | if we only talk about CLI, then agreed on the fact this is purely an OSC check | |
| 10:58:48 | bauzas | sean-k-mooney: and agreed on the fact the bindings should just be passthroughs to API calls | |
| 10:58:56 | bauzas | no smartness in therre | |
| 10:58:58 | bauzas | thereù | |
| 10:58:58 | bauzas | thereù | |
| 10:59:00 | bauzas | shit | |
| 10:59:02 | bauzas | there* | |
| 10:59:33 | sean-k-mooney | :) | |
| 10:59:48 | bauzas | whoami-rajat: so, as said, I'd appreciate if you could write a spec follow-up for this param | |
| 10:59:55 | bauzas | so we would agree on it | |
| 11:00:01 | sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/831014/4/openstackclient/compute/v2/server.py#3236 | |
| 11:00:10 | sean-k-mooney | that what i think we need to do in osc | |
| 11:00:13 | bauzas | as a reminder, some ops are reading our specs to understand the intents | |
| 11:00:40 | sean-k-mooney | i tought it was pretty clear | |
| 11:00:44 | sean-k-mooney | The python-novaclient, python-openstackclient and SDK will be updated | |
| 11:00:46 | sean-k-mooney | to support the new microversion. | |
| 11:01:00 | sean-k-mooney | then sepera sentance | |
| 11:01:02 | sean-k-mooney | n additional parameter ``--confirm-reimage`` will be added as a check | |
| 11:01:04 | sean-k-mooney | (along with the microversion check) on the client side that will determine | |
| 11:01:06 | sean-k-mooney | if the user really wants to opt into the new functionality. | |
| 11:01:12 | sean-k-mooney | i guess we can clarify the second one | |
| 11:01:19 | sean-k-mooney | and say openstack client | |
| 11:01:22 | bauzas | yes, I have problems with the second one | |
| 11:01:43 | bauzas | and yes, we should clarify the difference between the python client bindings and the shell commands | |
| 11:01:45 | sean-k-mooney | and "really wants to opt into" -> "to confime they want to proceed" | |
| 11:01:55 | whoami-rajat | ack will update that as well, client -> openstack client | |
| 11:01:55 | bauzas | yes | |
| 11:02:11 | bauzas | to opt-into means you can say no | |
| 11:02:22 | bauzas | but here, you can't say no if you set 2.93 | |
| 11:02:28 | sean-k-mooney | yep | |
| 11:02:46 | bauzas | I guess I was confused by the verb | |
| 11:03:18 | bauzas | and I guess operators can read they can turn off this even with 2.93 | |
| 11:03:25 | sean-k-mooney | i understood the intent but also have extra context which biases my interpritation | |
| 11:03:47 | bauzas | we just need to clarify there are no ways to refuse this contract if you specify 2.93 | |
| 11:03:55 | bauzas | (or later) | |
| 11:04:20 | bauzas | the check is purely a safety belt to ensure that the user knows what he's asking | |
| 11:04:33 | bauzas | this isn't a "check" | |
| 11:04:57 | bauzas | this is a "forced doubled signal" | |
| 11:13:39 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: MV 2.93 - Add support to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 11:16:20 | whoami-rajat | sean-k-mooney, bauzas ^ updated | |
| 11:22:22 | opendevreview | Amit Uniyal proposed openstack/nova stable/victoria: add regression test case for bug 1978983 https://review.opendev.org/c/openstack/nova/+/854979 | |
| 11:22:23 | opendevreview | Amit Uniyal proposed openstack/nova stable/victoria: For evacuation, ignore if task_state is not None https://review.opendev.org/c/openstack/nova/+/854980 | |
| 11:41:38 | whoami-rajat | sean-k-mooney, hey, so for checking if instance is BFV, should i check the "image" field and check if it's empty ? | |
| 12:38:53 | sean-k-mooney | whoami-rajat: i think that is likely the only way yes | |
| 12:39:05 | sean-k-mooney | unless you were to check this from cinder somehow | |
| 12:39:32 | sean-k-mooney | you do not have access to the bdm info at the api level | |
| 12:40:11 | sean-k-mooney | you can check the cinder attachment/volume info but i dont know if the re is a bfv ro i am the root disk flag on the cidner side that you can use | |
| 12:52:52 | whoami-rajat | sean-k-mooney, I don't think there's a root disk flag on the cinder side, we just have attachment info | |
| 12:52:53 | whoami-rajat | one other thing we've is if the volume is bootable or not but again we can do a normal attach on a bootable volume and it could not be a root disk | |
| 12:54:56 | sean-k-mooney | ya so for now checkign the server image filed is proably the best approch | |