| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 16:41:16 | gibi | as the new video dev has a fallback vga mode | |
| 16:41:17 | bauzas | gibi: I'm thinking hard of any potential upgrade implication | |
| 16:41:32 | sean-k-mooney | right so when we dicussed this before we decied to change it only for new instances to avoid upgrade issue | |
| 16:41:50 | bauzas | correct | |
| 16:41:57 | sean-k-mooney | our downstream QE tested this with windows guests and linux guest and both seamd to be ok with the change | |
| 16:42:01 | bauzas | I'm in favor of not touching the running instances | |
| 16:42:11 | bauzas | or asking to rebuild them | |
| 16:42:18 | gibi | we are not toching the running instance, we only touch hard rebooting instances | |
| 16:42:22 | sean-k-mooney | so kasyap has impletne this for all instnaces | |
| 16:42:49 | bauzas | gibi: which happens when you stop/start, right? | |
| 16:42:54 | gibi | right | |
| 16:42:54 | sean-k-mooney | bauzas: yes as gibi says it will only take effect when the xml is next regenreted | |
| 16:42:59 | gibi | it happens while the guest is not running | |
| 16:43:21 | gibi | it is not an unplug/plug for a running guest | |
| 16:43:29 | bauzas | do we want admins to opt-in instances ? | |
| 16:43:41 | bauzas | or do we agree it would be done automatically? | |
| 16:43:42 | sean-k-mooney | it will happen on start/stop hard reboot or a non live move operations | |
| 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 | |