| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 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 | |
| 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 | |