| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-07 | |||
| 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 | |
| 18:06:19 | sean-k-mooney | ok ya that should be the most flexiable | |
| 18:08:02 | sean-k-mooney | im kind fo torn, i guess this would be a new feature either on the cinder or nova side | |
| 18:08:17 | sean-k-mooney | for nova to enabel it we would need a new instance action | |
| 18:08:56 | sean-k-mooney | im not sure what woudl eb required on the cidner side to make it work if we did it form cinder insetead or if that is even possible | |
| 18:11:09 | sean-k-mooney | there is a complex back and forth between nova and cidner and the storage backend ot orchestrated depending on how the volume is attached and if the isntance is runnign so it wouldnt be a 1 liner to enabel unfrotuently | |
| 18:11:34 | luvn | oh, i see | |
| 18:11:56 | sean-k-mooney | for example for nfs if the vm is runnign nova need to grow the backign file on the nfs share (it cant be done by cidner) | |
| 18:12:13 | sean-k-mooney | for ceph that pretty easy you just need to ask ceph to grow it | |
| 18:12:54 | sean-k-mooney | for iscsi/fiber channel cinder woudl have to ask the storage backend to extend it and that may or may not be visabel to the guest before the iscisi export is remonted | |
| 18:14:03 | sean-k-mooney | the thing is we do supprot extnedign cidner volume when they are not the root volume (i dont recall in which casese it offline vs online) | |
| 18:14:06 | luvn | now i see why ceph is by far the most flexible heh | |
| 18:14:38 | luvn | in any case, i sent a message on cinder's channel; let's see if we can get a better insight into why these limitations exist | |
| 18:14:42 | luvn | i'm legit curious | |
| 18:15:22 | dansmith | likely because three connection mechanisms require three different paths, among other things :) | |
| 18:15:32 | dansmith | although in reserved state that should be not a problem I think | |
| 18:16:19 | sean-k-mooney | right reserved means for one that the vm is not running so cidner can alwasy do the opertion itself | |
| 18:16:42 | sean-k-mooney | the onely reason nova has to grow it for nfs when the vm is runnign is qemu has locked the file on the share | |
| 18:18:29 | sean-k-mooney | https://github.com/openstack/nova/blob/master/releasenotes/notes/nova-support-attached-volume-extend-88ce16ce41aa6d41.yaml | |
| 18:19:02 | luvn | so i guess there's a world where it's a matter of cinder allowing these operations to be performed when the volume is reserved | |