Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-16
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
17:01:10 bauzas #endmeeting
17:01:10 opendevmeet Meeting ended Tue Nov 16 17:01:10 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:01:10 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-16-16.00.html
17:01:10 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-16-16.00.txt
17:01:10 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-16-16.00.log.html

Earlier   Later