| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 16:48:03 | sean-k-mooney | for new boots or move operattions | |
| 16:48:13 | sean-k-mooney | we need to find another host that also supports it | |
| 16:48:38 | bauzas | that's why I tend to lean on option 2 | |
| 16:48:40 | sean-k-mooney | and we need this to work without any operator configurign of aggreates ectra | |
| 16:48:46 | bauzas | it's an interim solution | |
| 16:48:54 | dansmith | bauzas: me too, but 2 is not enough right? | |
| 16:49:07 | sean-k-mooney | option 2 works if an only if our min libvirt/qemu version are new enough | |
| 16:49:10 | dansmith | because you could be running an older libvirt/qemu | |
| 16:49:11 | enriquetaso | mmh, the volume attr says it's encrypted and the volume image format is qcow2: https://review.opendev.org/c/openstack/nova/+/854030/6/nova/virt/libvirt/utils.py | |
| 16:49:18 | dansmith | and I suspect it also depends on brick versions? | |
| 16:49:24 | enriquetaso | not sure to understand the questions | |
| 16:49:42 | sean-k-mooney | enriquetaso: i was asking because if we are booting a new vm we would need to look that up | |
| 16:49:55 | sean-k-mooney | and then include it as an input to placemnt and the schduler in some way | |
| 16:50:00 | bauzas | dansmith: hah, true, I was considering an API check, but that would require the libvirt versions, so nevermind my foolness | |
| 16:50:24 | bauzas | yeah, so that'a tuple (libvirt, compute) for accepted versions | |
| 16:50:26 | sean-k-mooney | well it may or may not again it depend on if our min version is above or below the ersion that intoduced it | |
| 16:50:44 | bauzas | you need libvirt AND compute versions to be recent enough | |
| 16:50:44 | enriquetaso | oh, the volume doesnt have anything special, it just volume type=nfs and encrypted=true sean-k-mooney | |
| 16:51:22 | dansmith | sean-k-mooney: yeah, well, that's a good reason not to just add the compute+libvirt+qemu into a trait IMHO | |
| 16:51:35 | sean-k-mooney | dansmith: right which is not what i suggested | |
| 16:51:57 | dansmith | I know :) | |
| 16:51:57 | sean-k-mooney | i very explictly said have a triat for the capablity to supprot lux in qcow | |
| 16:52:06 | gibi | dansmith: on the trait pollution: either we encode a list of versions as a capability on the compute side, or we expose those versions to the scheduler / placement and code up a similar mapping of capability - versions in the sceduler side. We just move around similar logic | |
| 16:52:40 | dansmith | gibi: yeah, understand, it's just that traits are supposed to be timeless right? | |
| 16:52:47 | bauzas | we have 5 mins to find a solution or defer to a spec, honestly | |
| 16:53:00 | dansmith | I'm not saying I know which solution (combination) is best, I'm just saying nothing feels particularly natural to me | |
| 16:53:19 | sean-k-mooney | so i was suggestign have the driver check the requirements and report COMPUTE_LUKS_IN_QCOW if it supprots it | |
| 16:53:50 | sean-k-mooney | and have a prefilter requesst that if the voluem was nfs and qcow and encrypted=true | |
| 16:54:01 | gibi | dansmith: we will have a bunch of traits yes, but I don't see what problem that causes. We never remove min compute version checks from the code either | |
| 16:54:07 | sean-k-mooney | and addtional have a min compute service check for the rooling upgrade case | |
| 16:54:36 | sean-k-mooney | the other thing about traits is they are ment to be virt driver independent | |
| 16:55:08 | gibi | LUKS_IN_QCOW does not seem to be libvirt dependent | |
| 16:55:13 | sean-k-mooney | to dans timeless point i.e. if we add one it shoudl be resuable by other virt driver | |
| 16:55:19 | sean-k-mooney | ya i was just thinking that | |
| 16:55:25 | sean-k-mooney | its the qcow bit but | |
| 16:55:32 | sean-k-mooney | we have that alredy | |
| 16:56:17 | sean-k-mooney | https://github.com/openstack/os-traits/blob/master/os_traits/compute/ephemeral.py#L18 and https://github.com/openstack/os-traits/blob/master/os_traits/compute/image.py#L28 | |
| 16:56:23 | sean-k-mooney | almost would work togather | |
| 16:56:43 | sean-k-mooney | btu we cant assume that epmeral encryption supprot for lux means nfs also works | |
| 16:56:58 | enriquetaso | LUKS_IN_QCOW is already a config option on Nova gibi ? | |
| 16:57:13 | sean-k-mooney | enriquetaso: not really | |
| 16:57:23 | sean-k-mooney | or not that im aware of | |
| 16:57:35 | sean-k-mooney | in the context of cinder | |
| 16:57:39 | gibi | enriquetaso: we are discussing creating a new placement trait to represent if a compute supports luks in qcow | |
| 16:57:54 | enriquetaso | gibi++ thanks | |
| 16:58:19 | bauzas | I honestly think we need to settle the dust | |
| 16:58:49 | bauzas | given the very short time we have left I hereby propose enriquetaso to create a spec and describe the feature | |
| 16:58:58 | bauzas | we could then chime on the upgrade concerns | |
| 16:59:06 | enriquetaso | okay u.u | |
| 16:59:15 | bauzas | enriquetaso: are you familiar with the spec process ? | |
| 16:59:26 | enriquetaso | is it too different from the cinder one? | |
| 16:59:39 | enriquetaso | bauzas, do you a have a doc? :P | |
| 16:59:55 | bauzas | enriquetaso: I can provide you pointers and more than that : guidance | |
| 17:00:11 | enriquetaso | sure bauzas | |
| 17:00:19 | bauzas | #agreed enriquetaso to provide a spec for this feature | |
| 17:00:33 | bauzas | #action bauzas to provide enriquetaso details on the spec process | |
| 17:00:40 | bauzas | we're on time | |
| 17:00:45 | bauzas | the agenda is done | |
| 17:00:56 | bauzas | so thanks all and see you next week | |
| 17:01:01 | bauzas | #endmeeting | |
| 17:01:01 | opendevmeet | Meeting ended Tue May 2 17:01:01 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:01 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.html | |
| 17:01:01 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.txt | |
| 17:01:01 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.log.html | |
| 17:01:06 | elodilles | thanks o/ | |
| 17:01:07 | enriquetaso | thansk!! | |
| 17:01:09 | bauzas | enriquetaso: gimme a sec | |
| 17:01:16 | enriquetaso | sure bauzas | |
| 17:01:42 | bauzas | enriquetaso: so the spec process is quite simple : it's a doc | |
| 17:01:52 | bauzas | enriquetaso: we have a template you can reuse https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/2023.2-template.html | |
| 17:02:41 | enriquetaso | looks good | |
| 17:02:45 | bauzas | enriquetaso: what you have to do is to write your own rst file based on that template and propose it for the approved/ directory | |
| 17:02:47 | bauzas | like https://review.opendev.org/q/project:openstack/nova-specs+is:open | |
| 17:03:07 | enriquetaso | bauzas, do you remember when is the spec freeze? | |
| 17:03:25 | sean-k-mooney | its milestone 2 | |
| 17:03:38 | sean-k-mooney | so after the physical ptg at the end of july | |
| 17:03:51 | bauzas | enriquetaso: sure, look https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-review-day | |
| 17:04:06 | bauzas | damn | |
| 17:04:06 | sean-k-mooney | july 6th actullly so start of july | |
| 17:04:20 | sean-k-mooney | https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-freeze | |
| 17:04:32 | bauzas | yup, my link was wrong | |
| 17:05:17 | bauzas | enriquetaso: honestly, as you understood, most of the review process on that file will consist on us to agree on the upgrade concerns | |
| 17:05:37 | bauzas | which are not only the rolling upgrade concerns but also the fact that we need a recent libvirt | |
| 17:05:55 | bauzas | enriquetaso: you know our minimum libvirt versions we support, right? | |
| 17:06:21 | enriquetaso | sorry | |
| 17:06:25 | enriquetaso | it desconnect | |
| 17:06:27 | enriquetaso | i'm back | |
| 17:06:37 | bauzas | enriquetaso: no worries | |
| 17:06:48 | enriquetaso | but I think I have all the info i need sean-k-mooney bauzas | |
| 17:06:53 | bauzas | I was mentioning that most of the spec review will be about the upgrade concerns | |
| 17:07:06 | bauzas | enriquetaso: our current minimums for libvirt are https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L219-L222 | |
| 17:07:21 | bauzas | sean-k-mooney: have you already proposed the libvirt min bump ? | |
| 17:08:42 | sean-k-mooney | no i asked kashyap to do that | |
| 17:08:53 | sean-k-mooney | i dont think they have had time to propose any patches | |
| 17:09:34 | kashyap | sean-k-mooney: Yes; it's on my list for this week | |
| 17:09:39 | bauzas | ack | |
| 17:09:45 | sean-k-mooney | if our currnt mins are enough this is simple as its just a min comptue service bump. if we have a min os-brick we can do that by raising or min os-brick | |
| 17:09:46 | kashyap | Right now I'm chasing down the kernel crash Dan pointed out earlier | |
| 17:10:19 | dansmith | can't do the min bump until I finish the ceph job stuff I think | |
| 17:10:50 | sean-k-mooney | it might be possibel but im ok waiting to m2 i guess | |