| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 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 | |
| 09:53:15 | stephenfin | I wasn't blaming you but if you want to take ownership | |
| 09:53:32 | stephenfin | You just seemed like someone that would appreciate such comments 0:) | |
| 09:53:57 | lyarwood | stephenfin: Aye it's a valid RFE of sorts | |
| 10:06:59 | gibi | it is good to see that stephen is bringing back honest feedback about our API usability. | |
| 10:07:06 | gibi | *stephenfin | |
| 10:07:24 | gibi | I have no clue who has the time to fix it | |
| 10:07:33 | gibi | but still the feedback is appreciated | |
| 10:08:09 | stephenfin | It could be something for future students to work on. I'll mention it to diablo_rojo | |
| 10:09:27 | sean-k-mooney[m] | im really not sure why we have a volume attaments api in nova iteslf. to me the atacment is not something we shoudl be exposing to users we should just have the volume resource associated with the server | |
| 10:10:04 | sean-k-mooney[m] | we dont expose port bindign in our api. they exist in neutorn but not in nova | |
| 10:10:19 | stephenfin | sean-k-mooney[m]: how would propose modifying e.g. the delete on termination behaviour for an attached volume in that scenario | |
| 10:10:24 | stephenfin | or doing volume swaps | |
| 10:10:31 | stephenfin | *how would you | |
| 10:10:43 | sean-k-mooney[m] | it would be an atibute on the volume | |
| 10:10:54 | sean-k-mooney[m] | and or set on the cinder resouce | |
| 10:10:55 | stephenfin | what about multi-attach volumes? | |
| 10:10:56 | sean-k-mooney[m] | not on novas | |
| 10:11:16 | sean-k-mooney[m] | you can have volume attaments they shoould just not be part fo the nova api | |
| 10:11:24 | stephenfin | this isn't a cinder thing, right? nova decides whether to delete $thing or not | |
| 10:11:33 | sean-k-mooney[m] | nova should have /server/uuid/volumes | |
| 10:11:51 | stephenfin | that's what we have :) | |
| 10:12:09 | sean-k-mooney[m] | that should just list the volume not the attacments | |
| 10:12:16 | stephenfin | /server/{server_id}/os-volumes | |
| 10:12:22 | sean-k-mooney[m] | all other data should be in cinder | |
| 10:13:06 | stephenfin | actually, no, tell a lie: the API is '/servers/{server_id}/os-volume_attachments' | |
| 10:13:10 | sean-k-mooney[m] | conceptually if you are working wiht the nova api you should not be thinking in terms of volume attachment but server and volume reosuces | |
| 10:13:26 | stephenfin | https://docs.openstack.org/api-ref/compute/?expanded=list-volume-attachments-for-an-instance-detail#list-volume-attachments-for-an-instance | |