| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 16:44:03 | gibi | bauzas: I trust kashyap that it is safe to change this device | |
| 16:44:14 | bauzas | do we also want to have a nova-status upgrade check for yoga about this ? | |
| 16:44:23 | sean-k-mooney | no | |
| 16:44:24 | bauzas | gibi: me too | |
| 16:44:29 | sean-k-mooney | why would we need too | |
| 16:44:35 | sean-k-mooney | we are not removing support for cirrus | |
| 16:44:36 | gibi | we don't remove cirros | |
| 16:44:41 | sean-k-mooney | jsut not the default | |
| 16:44:46 | gibi | yepp | |
| 16:45:00 | sean-k-mooney | gibi: context is downstream it is being remvoed form rhel 9 | |
| 16:45:04 | bauzas | sean-k-mooney: sure, that just means that long-living instances could continue running cirros | |
| 16:45:14 | sean-k-mooney | so wwe need to care about it for our product | |
| 16:45:24 | sean-k-mooney | actully cirrus is not beeing remvoed in rhel 9 | |
| 16:45:35 | sean-k-mooney | but like in rhel 10 | |
| 16:46:06 | sean-k-mooney | bauzas: yep which i think is ok | |
| 16:46:27 | sean-k-mooney | we coudl have a nova status check but it woudl have to run on the compute nodes | |
| 16:46:35 | sean-k-mooney | which is kind of not nice | |
| 16:46:40 | sean-k-mooney | since it woudl have to check the xmls | |
| 16:46:51 | bauzas | I know | |
| 16:46:53 | sean-k-mooney | so i woudl not add it personally | |
| 16:47:19 | bauzas | I'm just saying that we enter a time that could last long | |
| 16:47:20 | gibi | I agree, we don't need upgrade check | |
| 16:48:16 | sean-k-mooney | shal we continue this in the patch review | |
| 16:48:17 | bauzas | but agreed on the fact this is not a problem until cirros support is removed and this is not an upstream question | |
| 16:48:31 | bauzas | sean-k-mooney: you're right, nothing needing a spec | |
| 16:49:06 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device is accepted as specless BP for the Yoga release timeframe | |
| 16:49:10 | bauzas | moving on | |
| 16:49:12 | gibi | \o/ | |
| 16:49:17 | bauzas | next item | |
| 16:49:30 | bauzas | (kashyapc) Blueprint for review: "Add ability to control the memory used by fully emulated QEMU guests -- https://blueprints.launchpad.net/nova/+spec/control-qemu-tb-cache | |
| 16:49:39 | bauzas | again, a specless bp ask | |
| 16:49:54 | bauzas | he said " This blueprint allows us to configure how much memory a plain-emulated (TCG) VM, which is what OpenStack CI uses. Recently, QEMU changed the default memory used by TCG VMs to be much higher, thus reducing the no. of VMs you TCG could run per host. Note: the libvirt patch required for this will be in libvirt-v7.10.0 (December 2021)." | |
| 16:49:59 | bauzas | " See this issue for more details: https://gitlab.com/qemu-project/qemu/-/issues/693 (Qemu increased memory usage with TCG)" | |
| 16:50:21 | sean-k-mooney | im a little torn on this | |
| 16:50:41 | sean-k-mooney | im not sure i like this being a per host config option | |
| 16:50:51 | sean-k-mooney | but its also breaking existing deployemnts | |
| 16:51:04 | sean-k-mooney | so we cant really adress that with flavor extra specs or iamge properties | |
| 16:51:17 | sean-k-mooney | sicne it would be a pain for operators to use | |
| 16:51:17 | gibi | but that requires rebuild of existing instances | |
| 16:51:21 | sean-k-mooney | yep | |
| 16:51:32 | sean-k-mooney | so with that in mind the config option proably is the way to go | |
| 16:51:51 | sean-k-mooney | just need to bare in mind it might chagne after a hard reboot if you live migrate | |
| 16:51:53 | gibi | yeah, config as a first step, if later more fine grained control is needed we can add an extra_spec | |
| 16:52:24 | bauzas | there are libvirt dependencies | |
| 16:52:28 | sean-k-mooney | if we capture the (this should really be the same on all host in a region) pice in the docs im ok with this | |
| 16:52:37 | sean-k-mooney | bauzas: and qemu deps | |
| 16:52:37 | bauzas | you need a recent libvirt in order to be able to use it | |
| 16:52:43 | bauzas | right | |
| 16:52:45 | sean-k-mooney | its only supproted on qemu 5.0+ | |
| 16:52:45 | gibi | sean-k-mooney: yeah that make sense to document | |
| 16:53:05 | sean-k-mooney | so we will need a libvirt verion and qemu check in the code | |
| 16:53:12 | sean-k-mooney | which is fine we know how to do that | |
| 16:53:15 | bauzas | so, if this is a configurable, this has to explain which versions you need | |
| 16:53:23 | sean-k-mooney | yep | |
| 16:53:33 | bauzas | we would expose something unusable for the most | |
| 16:53:50 | sean-k-mooney | the only tricky bit will be live migration | |
| 16:54:02 | sean-k-mooney | if the dest is not new enough but the host is | |
| 16:54:04 | bauzas | correct, the checks ? | |
| 16:54:16 | sean-k-mooney | we will need to make sure we validate that | |
| 16:54:23 | bauzas | right | |
| 16:54:36 | bauzas | but this looks to me an implementation detail | |
| 16:54:50 | bauzas | all of this seems not needing a spec, right? | |
| 16:54:59 | bauzas | upgrade concerns are N/A | |
| 16:55:10 | bauzas | as you explicitely need a recent qemu | |
| 16:55:18 | sean-k-mooney | am the live migration check will be a littel complex but other then that i dont see a need for a spec | |
| 16:55:41 | sean-k-mooney | im a littel concerned about the livemgration check which is what makes me hesitate to say no spec | |
| 16:55:45 | bauzas | we can revisit this decision if the patch goes hairy | |
| 16:55:53 | sean-k-mooney | yes | |
| 16:55:55 | sean-k-mooney | that works for mee | |
| 16:56:25 | gibi | works for me too | |
| 16:56:36 | sean-k-mooney | i htink we have the hypervior version avaible in the conductor so i think we can do it without an rpc/object change | |
| 16:56:36 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/control-qemu-tb-cache can be a specless BP but we need to know more about the live migration checks before we approve | |
| 16:56:51 | bauzas | gibi: sean-k-mooney: works for you what I wrote ? | |
| 16:57:04 | sean-k-mooney | +1 | |
| 16:57:08 | bauzas | ok, | |
| 16:57:13 | bauzas | next topic is ganso | |
| 16:57:20 | bauzas | and eventually, whoami-rajat | |
| 16:57:27 | ganso | hi! | |
| 16:57:35 | bauzas | ganso: you have one min :) | |
| 16:57:50 | ganso | so my question is about adding hw_vif_multiqueue_enabled setting to flavors | |
| 16:57:56 | ganso | it was removed from the original spec | |
| 16:57:57 | ganso | https://review.opendev.org/c/openstack/nova-specs/+/128825/comment/7ad32947_73515762/#90 | |
| 16:58:06 | ganso | today it can be only used in image properties | |
| 16:58:26 | ganso | does it make at all semantically or is this something that only makes sense as an image property? | |
| 16:58:32 | sean-k-mooney | ya this came up semi recently | |
| 16:58:38 | sean-k-mooney | i think we can just add this in the flavor | |
| 16:58:49 | bauzas | the other way would be a concern to me | |
| 16:58:59 | ganso | ok. Would this require a spec? | |
| 16:59:00 | bauzas | as users could use a new property | |
| 16:59:20 | sean-k-mooney | well image propertise are for exposing thing that affect the virtualised hardware | |
| 16:59:24 | bauzas | but given we already accept this for images, I don't see a problem with accepting it as a flavor extraspec | |
| 16:59:30 | sean-k-mooney | so in gnerally you want that to be user setable | |
| 17:00:00 | ganso | great | |
| 17:00:07 | bauzas | sean-k-mooney: right, I was just explaning that image > flavor seems not debatable while flavor > image seems to be discussed | |
| 17:00:16 | ganso | to me it sounds simple enough to not require a spec, do you agree? | |
| 17:00:37 | bauzas | good question | |
| 17:00:45 | bauzas | but we're overtime | |
| 17:00:49 | sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/multiqueue-flavor-extra-spec | |
| 17:01:04 | sean-k-mooney | this is the implemation https://review.opendev.org/q/topic:bp/multiqueue-flavor-extra-spec | |
| 17:01:04 | bauzas | ganso: whoami-rajat: let's continue discussing your concerns after the meeting | |