Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-16
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
17:01:12 whoami-rajat ack
17:01:16 bauzas I need to leave
17:01:33 sean-k-mooney ganso: stephenfin was working on this before he moved team last cycle
17:01:41 bauzas ganso: about your ask, I'll put the specless bp acceptance to next week
17:01:44 sean-k-mooney ganso: i think we can do it as a specless blueprint
17:02:06 bauzas ganso: but we can basically agreed on this without waiting for it to be papered
17:02:14 bauzas agree*
17:02:15 sean-k-mooney ganso: all of the code is there i just didnt get time to pick it back up after stephenfin move so if you want to pick it up please do
17:02:29 ganso sean-k-mooney, bauzas thank you very much!!
17:03:23 gibi whoami-rajat: would be nice to have the reimage discussion when lyarwood is present
17:03:52 gibi I not feel knowledgeable enough in cinder
17:04:09 whoami-rajat gibi, ok, just wanted the team's thoughts on it, can you suggest a time that would be suitable?
17:05:36 gibi whoami-rajat: try to ping lyarwood tomorrow
17:06:10 whoami-rajat ok
17:06:10 gibi both me and bauzas was +2 on your spec so a quick chat with lyarwood would be enough
17:06:46 whoami-rajat ack, i will fix the gate failure and see what lyarwood thinks about it
17:19:43 opendevreview Dan Smith proposed openstack/nova master: WIP: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206
17:37:32 kashyap bauzas: Just back: on the blueprint for changing video model to "virtio": yes, you can trust the test results posted in the change. As noted, I've got it properly integration-tested for Windows and Linux guests with Red Hat virt QE
17:37:42 kashyap Also, gibi --^ (Thanks for the trust :))
17:38:42 gibi kashyap: :)
17:38:45 kashyap gibi: On context: it is not specific to downstream RHEL9 removing it (as sean-k-mooney phrased it). *Regardless* of what RHEL9 does it is not a good default. That's the bare argument.
17:38:58 kashyap "it" == Cirrus, I mean.
17:39:54 kashyap gibi: On the tb-cache thing: as a reminder, it is mostly used by CI setups that can't have KVM. All sensible production users will use KVM

Earlier   Later