| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-03 | |||
| 09:47:21 | sean-k-mooney | that not the problem its because you also happen to have a cinder backup at the same time | |
| 09:48:42 | sean-k-mooney | tobias-urdin: both nova and cidner backup exepct to be the only thing modifying the volume state when doign a resize or backup | |
| 09:49:25 | tobias-urdin | yea, i could just loop volumes and check status in the context and raise InstanceFaultRollback i guess for resize to not hit it, but there would still be a race between me checking the status and attachment code being called in resize | |
| 09:49:46 | sean-k-mooney | that not really the fix | |
| 09:49:58 | tobias-urdin | i was hoping i could reserve the volumes before starting the operation, but my research failed because it didn't accommodate for in-use not being possible on in-use volume :( | |
| 09:50:06 | sean-k-mooney | we either need nova to annotate the volume with somethjing to indicate that we are migrating | |
| 09:50:21 | sean-k-mooney | or we need to have cidner check the status of attached instnace before doing a backup | |
| 09:51:09 | sean-k-mooney | tobias-urdin: is cidner backup changing the state of the volume to something other then inuse | |
| 09:51:22 | tobias-urdin | yes "backing-up" is set | |
| 09:51:30 | sean-k-mooney | right os that also a bug | |
| 09:52:17 | sean-k-mooney | once a volume is attached to a nova instnace we do not exect the voluem status to change unless its via a call to the nova api | |
| 09:52:42 | sean-k-mooney | so form a nova perspecitve it should remain in use | |
| 09:53:02 | sean-k-mooney | it would be fine to have a seperate task_state that backing-up | |
| 09:54:05 | sean-k-mooney | but if cidner want to modify it they need to make the attchment api treat backing-up the same as in-use | |
| 09:54:41 | tobias-urdin | that actually makes more sense | |
| 09:55:24 | sean-k-mooney | we have a bunch of task_state that we translate to "active" because semanticly external service should treat them the same | |
| 09:56:31 | sean-k-mooney | i dont know how to express that in cidner api but i think if they have internal states liek backing-up they may need a similar mechanisum | |
| 09:59:08 | sean-k-mooney | like this https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L46-L63 | |
| 10:03:21 | tobias-urdin | sean-k-mooney: thanks for the directions! i will investigate further and see if i can find a better path forward | |
| 10:04:03 | sean-k-mooney | ill try an comment on the bug and maybe a good dicusion for the ptg in a nova/cinder cross project if we dont have a path forward by then | |
| 10:08:49 | tobias-urdin | sean-k-mooney: ack, looks like they account for some migration logic in _attachment_reserve() https://github.com/openstack/cinder/blob/master/cinder/volume/api.py#L2409 | |
| 10:09:31 | tobias-urdin | so imo handling backing-up (if "previous status", that it sets back when backup is complete, is in-use) as if it were in-use makes sense | |
| 10:44:59 | sean-k-mooney | tobias-urdin: https://bugs.launchpad.net/nova/+bug/2077512/comments/5 i tried to summeriese my toughts and i added cinder to the bug | |
| 13:10:48 | tobias-urdin | sean-k-mooney: this is the real path forward https://review.opendev.org/c/openstack/cinder-specs/+/915973 instead of my new hack approach https://review.opendev.org/c/openstack/cinder/+/943176 | |
| 13:54:58 | opendevreview | Merged openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | |
| 14:04:29 | sean-k-mooney | tobias-urdin: ah yes that does seam to be adressign this edgecase | |
| 15:41:38 | cardoe | hello. hoping to get https://review.opendev.org/c/openstack/nova/+/942019 into 2025.1. This fixes an issue in 2024.1 and 2024.2 when you use Ironic and Nova is unable to deploy the error message is just the name of the OpenStack SDK object and the memory address instead of the actual error message. | |
| 15:49:34 | sean-k-mooney | cardoe: ah i skimmed that. im not sure if we want to merge that in the RC period but i think its mostly a vailid change | |
| 15:49:51 | sean-k-mooney | cardoe: my main question is did it report "No Error" | |
| 15:50:01 | sean-k-mooney | before when usign ironic client? | |
| 15:50:33 | cardoe | It printed an empty string | |
| 15:50:49 | cardoe | It felt awkward so I added that. | |
| 15:51:08 | sean-k-mooney | ok so im not sure if we would want to maintain the old behivor or not | |
| 15:51:27 | cardoe | It said "(deploy: power: some message storage: )" | |
| 15:51:28 | sean-k-mooney | i think no error is ok | |
| 15:51:40 | sean-k-mooney | oh | |
| 15:51:51 | sean-k-mooney | they ya its better with teh current version | |
| 15:52:09 | sean-k-mooney | wha ti was going to suggest is only inluciding the one that had an error | |
| 15:52:22 | sean-k-mooney | btu that could break people if they depeneded on all 3 being there | |
| 15:52:25 | cardoe | Now it says "(deploy: <openstack.response 0xDEADBEEF> power: <openstack.response 0xBEEFDEAD> storage: <openstack.response 0xFFFFFFFF)" | |
| 15:52:46 | cardoe | My patch makes it say "(deploy: No Error power: some message storage: No Error)" | |
| 15:53:03 | sean-k-mooney | ya which is an improvmenet over the old and current behavior | |
| 15:53:44 | cardoe | I was originally gonna drop the "deploy:" and "storage:" section if there wasn't a problem. But like you said, if people are expecting it I didn't wanna break them. | |
| 15:54:45 | sean-k-mooney | i have not looked at this in deaile but the other question i was wondering about is is this only looged or can this be returned to an end user | |
| 15:55:04 | cardoe | It's only logged today. I wanna return it to the user. | |
| 15:55:28 | sean-k-mooney | ok so the warning i was oging ot give is these mesagges come from ironic | |
| 15:55:35 | cardoe | I'm refactoring a few parts of that because today the user gets "Failed to prepare block device" as the error for nearly everything. | |
| 15:55:42 | sean-k-mooney | it many not be ok to show that to a user unless they are admin | |
| 15:55:58 | cardoe | Like if the VIF cannot be attached or created in Neutron, the error is still "Failed to prepare block device" | |
| 15:56:07 | sean-k-mooney | fun | |
| 15:56:37 | sean-k-mooney | we can give them a better message but we cant including things like ipmi details of the node ectra | |
| 15:56:39 | cardoe | But I figured that wasn't a backportable change so I tried to split this up into 2 changes. One to just fix the log message and then one that'll be a behavior change and would go in a future release. | |
| 15:57:00 | sean-k-mooney | ya it should be two diffent patches at any rate | |
| 15:57:49 | sean-k-mooney | depending on what it looks like it may or may not be backportable but we just have to be carful to not let them see info that you can only see as an admin | |
| 15:58:09 | cardoe | right | |
| 15:58:48 | sean-k-mooney | cardoe: so my main ask on this patch would be to add a unit test | |
| 15:59:00 | cardoe | okay will do | |
| 15:59:09 | sean-k-mooney | basiclly just assert the log message is printed with the expect values | |
| 15:59:13 | sean-k-mooney | otherwise i think its fine | |
| 15:59:23 | cardoe | makes sense. I'll add it. | |
| 16:03:57 | sean-k-mooney | cool i just captured that in a comment on the patch | |
| 16:07:16 | sean-k-mooney | cardoe: tiraged https://bugs.launchpad.net/nova/+bug/2100009 we dont have an offical rc lable yet but it will be called epoxy-rc-potential so i added that premtively | |
| 16:11:17 | cardoe | Thanks | |
| 18:02:56 | sean-k-mooney | bauzas: jsut an fyi we still need to merge the linux bridge deprecation patch in nova https://review.opendev.org/c/openstack/nova/+/942291 | |
| 19:10:10 | melwitt | fyi the fix for the tpool proxy listDevices() regression needs a second +2 for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/942652 and the func test below it, if anyone could take a look. it will need to be reviewed for stable/2024.1, stable/2023.2, and unmaintained/2023.1 also 😕 | |
| 19:10:39 | sean-k-mooney | i can take a look shortly | |
| 19:11:18 | melwitt | thanks sean-k-mooney | |
| 19:15:20 | sean-k-mooney | +2w on 2024.2 ill try to remember to loop back to 2024.1 tomorrow | |
| 19:15:35 | sean-k-mooney | if not feel free to ping | |
| 19:16:12 | melwitt | ok, thank you sean-k-mooney | |
| 20:09:58 | opendevreview | Merged openstack/nova stable/2024.2: Reproducer for bug 2098892 https://review.opendev.org/c/openstack/nova/+/942651 | |
| 20:23:20 | opendevreview | ribaudr proposed openstack/nova master: Update driver to map the targeted address for SR-IOV PCI devices https://review.opendev.org/c/openstack/nova/+/942147 | |
| 20:23:21 | opendevreview | ribaudr proposed openstack/nova master: Update libvirt fixtures to support hostdevs https://review.opendev.org/c/openstack/nova/+/943207 | |
| 20:23:21 | opendevreview | ribaudr proposed openstack/nova master: FUP improve comment accuracy and variable naming for tag removal https://review.opendev.org/c/openstack/nova/+/943124 | |
| #openstack-nova - 2025-03-04 | |||
| 01:38:25 | opendevreview | Merged openstack/nova master: Fix microversion 2.96 for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942875 | |
| 01:45:15 | opendevreview | Merged openstack/nova master: Fix microversion 2.98 doc/tests for update/rebuild APIs https://review.opendev.org/c/openstack/nova/+/942878 | |
| 09:49:58 | elodilles | stephenfin: when you have a minute, could you please unblock nova's and other repos stable/2024.* gates with this CI-only openstacksdk fix? https://review.opendev.org/c/openstack/openstacksdk/+/943182 | |
| 09:50:04 | elodilles | thanks in advance! o:) | |
| 09:56:05 | stephenfin | elodilles: Do we want to remove that from the master branch? | |
| 09:57:46 | elodilles | stephenfin: in the past you said it's better to test things with openstacksdk on stable branches as long as it is possible, so i don't need it to be removed if you still want that | |
| 10:00:43 | elodilles | s/openstacksdk/openstacksdk from master branch/ | |
| 10:01:41 | elodilles | (maybe stable/2025.1 can be tested longer with master branch than stable/2024.2 lasted o:)) | |
| 10:02:06 | elodilles | thanks for the review stephenfin o/ | |
| 10:15:45 | stephenfin | elodilles: yeah, I think it's a good goal in theory to test modern SDK with older releases. However, the need for co-installability is what's killing us. idk if it's realistically possible to avoid that. I suspect not, seeing as it's used in services as well as clients | |
| 10:18:25 | elodilles | yeah, probably true. i'm OK with removing the branch-override then on master to avoid this issue in the future. | |
| 10:23:22 | stephenfin | elodilles: https://review.opendev.org/c/openstack/openstacksdk/+/943236 (as your not in #openstack-sdks) | |
| 10:23:27 | stephenfin | *you're | |
| 13:12:49 | stephenfin | sean-k-mooney: mikal: melwitt: We missed as opportunity to address a small but easy TODO in the console auth token API schemas in v2.99. I assume it's too late to address now? https://github.com/openstack/nova/blob/406eedb1cecf720163516fb9c8e7b149303fb057/nova/api/openstack/compute/schemas/console_auth_tokens.py#L13 | |
| 13:24:28 | sean-k-mooney | stephenfin: we could probaly do that in isolation as a single patch | |
| 13:24:38 | sean-k-mooney | assuming we dont need the rest of the seriese | |
| 13:25:28 | sean-k-mooney | its sort of a bugfix but it porably should be its own microversion | |
| 13:25:45 | sean-k-mooney | im not sure how gmann would fell about adding it to 2.99 | |
| 13:26:16 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for for console auth token APIs (v2.99) https://review.opendev.org/c/openstack/nova/+/943252 | |
| 13:26:16 | opendevreview | Stephen Finucane proposed openstack/nova master: api: project/tenant and user IDs are not UUIDs https://review.opendev.org/c/openstack/nova/+/940369 | |
| 13:26:17 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Address TODO in microversion v2.99 https://review.opendev.org/c/openstack/nova/+/943253 | |
| 13:26:33 | sean-k-mooney | strictly speaking once its merged in master we have to treat it as if its released but practically if its done before rc1 it probaly ok | |
| 13:27:00 | stephenfin | sean-k-mooney: The patch is there, along with one to correct the response body schemas (which are currently incorrect) and the removal of the incorrect "user/project IDs should be UUIDs" assumption | |
| 13:27:45 | sean-k-mooney | looking at the title i agree that including those 3 patches in epoxy is a good idea | |
| 13:27:56 | sean-k-mooney | we should proably highlight this in the irc meeting later | |
| 13:27:59 | stephenfin | the sooner we get https://review.opendev.org/c/openstack/nova/+/936366 and https://review.opendev.org/c/openstack/nova/+/936367 in, the better. What's there is too magical IMO. Definitely one for early in F | |