| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 16:42:58 | sean-k-mooney | but in any case we want this to work without any configuration requried | |
| 16:43:20 | sean-k-mooney | bauzas: why not just do 2? | |
| 16:43:24 | gibi | I might miss something but if this feature nees compute code + libirt/qemu version then as simple compute version check is not enough | |
| 16:43:34 | dansmith | sean-k-mooney: Im saying make it integrated | |
| 16:43:44 | dansmith | sean-k-mooney: kinda like a prefilter | |
| 16:43:56 | bauzas | wait https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L399 | |
| 16:44:17 | dansmith | gibi: yeah, you need service version and libvirt version and qemu version right? | |
| 16:44:20 | sean-k-mooney | so if feature x requries minv version y have a prefilter or simialr that will request a host with that min version | |
| 16:44:25 | bauzas | that's ephemeral encryption | |
| 16:44:50 | sean-k-mooney | ya thats seperate | |
| 16:44:56 | sean-k-mooney | we are talkign about encyption for nfs | |
| 16:45:09 | sean-k-mooney | for cinder volume backend that use nfs | |
| 16:45:10 | dansmith | gibi: that's kinda why I just think this is trait pollution because we end up with all these feature flags for any possible combination of several versions | |
| 16:45:24 | dansmith | and especially in three years, that trait is useless as everything exposes it all the time | |
| 16:45:55 | dansmith | so I'm not sure what the best plan is here, to be clear, I'm just saying none of these simple things feels right | |
| 16:46:07 | sean-k-mooney | dansmith: not really usign a trait we report an abstract capblity. but in general i would prefer both a trait and a compute version bump | |
| 16:46:43 | dansmith | that's the thing though: | |
| 16:47:02 | sean-k-mooney | enriquetaso: how is this feature requested on teh volume by the way? | |
| 16:47:08 | dansmith | just exposing a "can do nfs encryption" because all the versions are new enough just feels like we could have a thousand of those things | |
| 16:47:20 | enriquetaso | when attaching the volume sean-k-mooney | |
| 16:47:35 | sean-k-mooney | how exactly a atribute on the volume | |
| 16:47:44 | sean-k-mooney | enriquetaso: we have two distict but related problems | |
| 16:47:55 | sean-k-mooney | for attachemtn we know the host and have to check if the host suprot this | |
| 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 | enriquetaso | oh, the volume doesnt have anything special, it just volume type=nfs and encrypted=true sean-k-mooney | |
| 16:50:44 | bauzas | you need libvirt AND compute versions to be recent enough | |
| 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 | sean-k-mooney | i very explictly said have a triat for the capablity to supprot lux in qcow | |
| 16:51:57 | dansmith | I know :) | |
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.html | |
| 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 | bauzas | #endmeeting | |
| 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 | |