| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-07 | |||
| 16:45:52 | sean-k-mooney | sorted is just for determinium | |
| 16:45:58 | sean-k-mooney | dansmith: no worries | |
| 16:46:15 | dansmith | determinism .. yeah, let's do something like that if we care, for sure | |
| 16:46:20 | gibi | bauzas: it could be a last run timestamp if we don't like age | |
| 16:46:55 | gibi | bauzas: but as we hav age we have a good set of value to find a single scheduler that min / max in that value to be the only one to do the work | |
| 16:46:57 | bauzas | well, | |
| 16:47:24 | sean-k-mooney | so for today what i really want to knwo is spec, bug or specless bluepritn so i know if we have till thurday or m3 to finalise the design and implamations | |
| 16:47:47 | bauzas | there are possibilities where a nova-scheduler could see itself being the oldest while another one, runnning 2 secs later could also see it as the oldest | |
| 16:47:59 | sean-k-mooney | that why im not using time | |
| 16:48:06 | sean-k-mooney | im sorting on the value of host | |
| 16:48:10 | bauzas | I know | |
| 16:48:18 | bauzas | but that's still the same | |
| 16:48:23 | dansmith | bauzas: sort by id, filter by up, that should be stable | |
| 16:48:33 | bauzas | some host could see itself as up while someother too, 1 sec later | |
| 16:48:55 | dansmith | if it does, then it's flapping from the view of the operator, which I think is not likely to be unnoticed | |
| 16:49:23 | sean-k-mooney | also people run with this in production without this protection or any kind fo arbitation today. | |
| 16:49:31 | bauzas | dansmith: if you are okay with operators unnoticing which nova-scheduler runs where, then ok | |
| 16:49:35 | sean-k-mooney | i.e. the just ignor the longs when there is a collioson | |
| 16:49:47 | dansmith | bauzas: which nova scheduler runs...host discovery? | |
| 16:49:53 | bauzas | yes | |
| 16:50:10 | sean-k-mooney | why would the care? | |
| 16:50:15 | dansmith | isn't that the point of this? instead of run-everywhere it's run-one-place, automatically managed? | |
| 16:50:28 | dansmith | right now, they can all run it in parallel all the time, if you care, but that's expensive | |
| 16:50:46 | gibi | ^^ yepp | |
| 16:50:51 | dansmith | I thought the point was to make it less expensive and automatically decide that (hopefully) only one does it each time.. seems fine to me | |
| 16:50:52 | bauzas | OK, then let's go for the proposal | |
| 16:50:57 | dansmith | worst case, two do it, no problem | |
| 16:51:10 | sean-k-mooney | yep ^ | |
| 16:51:12 | bauzas | well, you're right | |
| 16:51:22 | bauzas | two running at same time don't split brains | |
| 16:51:38 | bauzas | because of the periodic itself | |
| 16:51:41 | sean-k-mooney | they dont even cause an error if you have not added any hosts | |
| 16:51:52 | dansmith | yeah | |
| 16:51:58 | bauzas | okay, then to answer sean-k-mooney's question, I'm fine with it being specless | |
| 16:52:08 | bauzas | I actually would prefer it to be specless please | |
| 16:52:32 | bauzas | as I wouldn't want to step into DLM muds and leader elections | |
| 16:52:40 | sean-k-mooney | ok i think ill file a new bluepritn for ti and update the description | |
| 16:52:54 | sean-k-mooney | if we are ok with that are we ok to appove that async | |
| 16:52:58 | bauzas | sure | |
| 16:53:08 | sean-k-mooney | ill do it now and ping outside fo the meeting | |
| 16:53:36 | bauzas | #agreed https://review.opendev.org/c/openstack/nova/+/938523 can be filed as a specless blueprint | |
| 16:53:54 | s3rj1k | sean-k-mooney: thanks for spending time on this | |
| 16:53:55 | bauzas | cool thanks | |
| 16:54:30 | sean-k-mooney | s3rj1k: no worreis i ment to do it before going on pto i just didnt finish hacking on it until i got back on monday | |
| 16:54:54 | sean-k-mooney | ok thats if from me | |
| 16:55:05 | sean-k-mooney | s/if/it/ | |
| 16:55:52 | bauzas | cool | |
| 16:55:55 | bauzas | thanks all then | |
| 16:55:59 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-07-16.01.log.html | |
| 16:55:59 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-07-16.01.txt | |
| 16:55:59 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-07-16.01.html | |
| 16:55:59 | opendevmeet | Meeting ended Tue Jan 7 16:55:58 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:55:59 | bauzas | #endmeeting | |
| 16:56:27 | elodilles | thanks o/ | |
| 16:56:43 | s3rj1k | thanks | |
| 16:58:55 | gibi | thanks folks | |
| 17:22:45 | sean-k-mooney | s3rj1k: bauzas: i think https://blueprints.launchpad.net/nova/+spec/distributed-host-discovery covers it | |
| 17:26:41 | s3rj1k | yea, looks good | |
| 17:40:24 | luvn | hey guys! in openstack, is it possible — through some workaround — to detach a boot volume to extend and/or retype it? | |
| 17:41:40 | luvn | i found an old spec related to this but as far as i know it never moved forward — https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/detach-boot-volume.html | |
| 17:42:05 | luvn | so i was just wondering if we have a workaround for that | |
| 17:45:22 | dansmith | I want to say you might be able to shelve/offload a BFV instance and take action on the volume, but don't quote me | |
| 17:51:14 | sean-k-mooney | dansmith: i think when shleved its in the reserved state, im not sure if cinder will allow exented then but perhaps. | |
| 17:51:33 | sean-k-mooney | luvn: but no we dont allow detach of the root volume for bfv guests | |
| 17:51:36 | dansmith | yeah idk, but I think it's detached from the host which definitely keeps it pinned | |
| 17:51:53 | sean-k-mooney | i think you can do retpe without special workarounds | |
| 17:52:05 | sean-k-mooney | im also not sure if you can just do live extened | |
| 17:52:10 | sean-k-mooney | you can for non root voluems | |
| 17:52:27 | sean-k-mooney | luvn: i assume you tried just extending via cinder and it was unhappy | |
| 17:54:59 | dansmith | retyping often means a different connection_info right? | |
| 17:55:14 | opendevreview | Douglas Viroel proposed openstack/nova master: WIP - Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | |
| 17:55:19 | sean-k-mooney | ya but that calls the swap volume api right | |
| 17:55:21 | luvn | that's right, i did a quick experiment on devstack and was unsuccessful :( | |
| 17:55:33 | luvn | you can't really retype/resize the volume when it's reserved | |
| 17:55:42 | dansmith | sean-k-mooney: idk, I didn't think so | |
| 17:55:48 | luvn | (which is the state shelving brings it to) | |
| 17:56:03 | sean-k-mooney | dansmith: i dont really know of a reason that the root volume shoudl be diffent form a data volume with resepct to resize/retype | |
| 17:56:21 | sean-k-mooney | im not say it not diffent just unsure what the reason woudl be for them to behave differntly | |
| 17:56:55 | dansmith | sean-k-mooney: well, I guess I don't really know the story here.. I thought swap_volume was mostly for snapshots and things but maybe it should/would work for retype | |
| 17:57:12 | dansmith | I guess the detach-and-reattach-elsewhere is the thing that is most special about BFVs | |
| 17:59:05 | sean-k-mooney | right becasue we dont want to allow an isntance to not have an assocated root disk | |
| 17:59:27 | sean-k-mooney | but retype or extend shoudl not impact that so im not sure either if it can work or not | |
| 18:00:20 | sean-k-mooney | shelve is worth a shot but i have never tired if im being honest | |
| 18:00:33 | dansmith | sounds like luvn has | |
| 18:01:06 | sean-k-mooney | oh because its not allwoed in reserved state | |
| 18:01:28 | sean-k-mooney | perhaps its worth askign cinder about why that is. | |
| 18:01:29 | luvn | yup, that's right | |
| 18:01:43 | dansmith | luvn: and to be clear you've tried with it attached/running as well right? | |
| 18:02:32 | luvn | dansmith: i did! i don't really remember the output rn, but it complained about the volume status as well | |
| 18:03:04 | dansmith | ack | |
| 18:03:12 | dansmith | that's consistent with how I thought it worked | |
| 18:03:23 | dansmith | (or didn't) | |
| 18:04:19 | luvn | okay, so with the instance running and the volume attached: | |
| 18:04:20 | sean-k-mooney | that reminds me that we still have not completed https://review.opendev.org/c/openstack/nova/+/873560 | |
| 18:04:24 | sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/assisted-volume-extend | |
| 18:04:28 | luvn | resize: Failed to set volume size: Volume is in in-use state, it must be available before size can be extended | |
| 18:04:41 | luvn | retype: Failed to set volume type: Invalid volume: Retype needs volume to be in available or in-use state, not be part of an active migration or a consistency group, requested type has to be different that the one from the volume, and for in-use volumes front-end qos specs cannot change. | |
| 18:05:18 | luvn | retyping appears to be more "loose" than resize, but still, can't really perform it | |
| 18:05:38 | sean-k-mooney | what storage backend are you using out of interest | |
| 18:06:07 | luvn | i'm using ceph | |