| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-06 | |||
| 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 | bauzas | yes | |
| 11:01:55 | whoami-rajat | ack will update that as well, client -> openstack client | |
| 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 | |
| 13:26:14 | opendevreview | Amit Uniyal proposed openstack/nova master: add regression test case for bug 1552777 https://review.opendev.org/c/openstack/nova/+/855900 | |
| 13:26:15 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check for instance resizing https://review.opendev.org/c/openstack/nova/+/855901 | |
| 13:39:25 | elodilles | bauzas: may i update the meetings page stable section or you are editing the page currently? | |
| 13:39:37 | bauzas | elodilles: please do it | |
| 13:39:42 | elodilles | ++ | |
| 13:42:06 | elodilles | bauzas: done | |
| 14:15:54 | sean-k-mooney | looks like we might have a gap in our test fixtures | |
| 14:16:28 | sean-k-mooney | https://paste.opendev.org/show/bageEC5wOh09aqjEJyGG/ | |
| 15:00:54 | bauzas | reminder: nova meeting in 1 hour here | |
| 15:12:48 | Uggla | oops I have just realized, I completely forget about the bug week baton. :( | |
| 15:13:07 | Uggla | I can do it again this week. If you wish. | |
| 15:13:08 | bauzas | Uggla: no problem at all, this is purely optional work | |
| 15:13:15 | bauzas | Uggla: heh, fer sur | |
| 15:13:40 | bauzas | the bug number only increased by 2. | |
| 15:13:46 | bauzas | 9 "new" bugs | |
| 15:14:15 | Uggla | shame on me. :) | |
| 15:14:22 | bauzas | no shame at all | |
| 15:14:31 | bauzas | I had the same situation when I was in Berlin :) | |
| 15:29:10 | bauzas | gmann: around ? | |
| 15:29:46 | bauzas | gmann: fwiw, I'll discuss https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html at the nova meeting, I'd appreciate if you could be around when we discuss to clarify any question | |
| 15:30:06 | dansmith | bauzas: nova just needs to sign up for one of the slots, | |
| 15:30:18 | dansmith | and plan to have operator-focused discussions during that slot | |
| 15:30:26 | bauzas | sure, I understood it | |
| 15:30:32 | dansmith | likely for a "pain points" sort of thing, or other things they want to bring up | |
| 15:30:33 | dansmith | okay | |
| 15:30:33 | bauzas | but any case of any fancy question | |
| 15:30:41 | bauzas | I couldn't be able to answer | |
| 15:30:59 | dansmith | I'll be around and should be able to answer questions | |
| 15:31:27 | bauzas | what I also understood is that there is no reason to keep a competitive timeslot for the project as a different room | |
| 15:32:12 | bauzas | like, if I was choosing Tuesday 1pm UTC, I should unbook the nova timeslot in the bexar room | |
| 15:32:39 | bauzas | but we'll figure it out | |
| 15:32:50 | dansmith | no, | |
| 15:33:26 | dansmith | I think nova just needs to choose a slot and make sure our schedule lines up for that session during that slot.. I thought it was supposed to be in the nova room, not a separate one | |
| 15:34:32 | dansmith | I guess maybe he just put them in some room in order to lodge the timeslot, but I think it should be rescheduled to our room in that slot | |
| 15:34:59 | dansmith | yeah "projects can convert/reserve them" | |
| 15:34:59 | bauzas | yup, I was about to unbook the nova-placement slot accordingly but reuse this timeslot with the operator-nova-friendly track or whatever this is called | |