Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-16
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
17:40:31 kashyap Unless they have some need to run emulated-only guests -- because the performance is cripplingly slow compared to hardware-accelerated virt
17:40:41 gibi yeah good point
17:40:57 gibi it is for a specific non production use case
17:40:59 clarkb kashyap: there are production use cases for emulation though. For example docker image builds for different architectures (we do a bunch of that)
17:41:14 clarkb That doesn't concern nova, but it should be something that qemu/libvirt consider
17:41:31 clarkb basically the emulation use case shouldn't simply be dismissed
17:42:05 kashyap clarkb: Heya. Fully agree - that's a valid use-case. :-) But I was speaking from a compute-workload point of view: 90% of them are on KVM driver
17:42:44 kashyap clarkb: Enabling cross-arch builds is one of the appealing points, sure.
17:43:11 kashyap clarkb: Although, my use of "sensible production users" is a bit dismissive, I agree. Sorry :)
17:43:29 sean-k-mooney kashyap: rackspace used to run there public cloud using qemu for x86 on power hardware for a long time
17:45:30 kashyap sean-k-mooney: Sure; but it's also far, far, less secure. And upstream QEMU doesn't have any security guranatees
17:45:45 sean-k-mooney kashyap: yep and that is fine for many
17:46:27 sean-k-mooney espically if they use selinxu/contiaer to add an extra laywer of security around the qemu instancve
17:46:39 kashyap sean-k-mooney: Sure; as long as they're aware of it. I just double-checked with the QEMU folks: they "explicitly *disclaim* any security for TCG"
17:46:48 sean-k-mooney yes i kno
17:46:51 sean-k-mooney know
17:46:55 sean-k-mooney its in there wiki
17:47:11 kashyap Public docs: https://qemu-project.gitlab.io/qemu/system/security.html
17:47:12 sean-k-mooney https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
17:47:17 kashyap Yep.
17:50:53 kashyap sean-k-mooney: Note, though; SELinux/AppArmour can mitgate *some* of the risk, but as the QEMU folks say elsewhere: "depending on the config you can still have *massive* holes you can drive a truck through" (Cc: gibi, clarkb)
17:51:20 clarkb sure, I'm not saying it is a good idea for production cloud VM usage. But I do think there are valid use cases out there
17:52:10 kashyap Agreed. I was just tempering the "production cloud w/ TCG" usage point-of-view. In case any lurkers are observing this conversation, I wanted to plug the security implications here
17:53:27 sean-k-mooney i dont really think its a debate there have been several production largescase cloud that did run with just qemu
17:53:51 sean-k-mooney depening on your security model it may or may not be an issue
18:01:02 kashyap Also Rackspace used to offer Xen too. Not just plain QEMU.
18:02:43 kashyap I don't want belabour this point. I wonder who are these "largescale clouds". Overall, any serious user who wants to run non-toy compute workloads will not use plain emulation.
18:03:22 kashyap Anyhow...time to wrap up the day.
19:11:04 dasp sean-k-money: I opened the BP like you suggested but didn't tag it for yoga properly, so it may have been missed: https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types
19:12:18 sean-k-mooney am we will tag it when its review but you just need to add it to the metting adgenda by updating the wiki
19:12:50 opendevreview Rodrigo Barbieri proposed openstack/nova master: Add 'hw:vif_multiqueue_enabled' flavor extra spec https://review.opendev.org/c/openstack/nova/+/792356
19:17:07 dasp sean-k-mooney: thanks, done
20:19:49 opendevreview Artom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration https://review.opendev.org/c/openstack/nova/+/817778
#openstack-nova - 2021-11-17
00:06:57 opendevreview Ghanshyam proposed openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011
00:10:28 gmann dansmith: sean-k-mooney melwitt gibi ^^ please review the 'project admin boot server on host' spec. I have proposed to modify the existing field but if that break user I am ok on adding new field too.
00:10:40 gmann gibi: also please remove your procedural -2.
06:22:53 gibi gmann: I dropped the -2, I will review the spec later today
06:27:09 opendevreview Rajat Dhasmana proposed openstack/nova-specs master: Add spec for volume backed server rebuild https://review.opendev.org/c/openstack/nova-specs/+/809621
07:03:35 bauzas good morning Nova
09:42:47 stephenfin lyarwood: Can I just say that our volume attachment APIs are exceptionally...weird? :-D There doesn't seem to be any way to fetch an attachment by its own ID (you have to use the server and volume IDs), and you need to pass a volume ID when updating an attachment, even if you're only changing the delete on termination behavior
09:43:56 stephenfin (the students we're mentoring are running into bugs with openstacksdk caused by, I think, misunderstandings of how that API is supposed to work)
09:52:26 lyarwood stephenfin: \o morning (just back online after a few days off sick)
09:52:32 lyarwood stephenfin: wait my APIs? ^_^
09:53:07 stephenfin lyarwood: Oh, sorry to hear, hope you're feeling better /o\
09:53:08 lyarwood stephenfin: They pre-date me buddy but you're right that there's no support for Nova's attachment UUID to be used to lookup things

Earlier   Later