| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 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 | |
| 10:15:20 | sean-k-mooney[m] | really all nova should be tracking in its api is the volume uuid is associated with the server | |
| 10:15:39 | sean-k-mooney[m] | perhaps the status of the volume too | |
| 10:15:45 | stephenfin | the mount point? | |
| 10:16:05 | sean-k-mooney[m] | not the mount point the tag yes since that is a nova concept | |
| 10:16:24 | sean-k-mooney[m] | we dont actully guarentee the mount point and in libvirt it is jut not correct | |
| 10:17:09 | sean-k-mooney[m] | if you specifiy the mount point name there is no way for libvit to enforce it | |
| 10:17:15 | stephenfin | oh, I didn't know that | |
| 10:17:41 | stephenfin | we should _probably_ mention that in the API ref | |
| 10:17:50 | lyarwood | it is | |
| 10:18:09 | lyarwood | https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-instance-detail#attach-a-volume-to-an-instance | |
| 10:18:15 | lyarwood | Name of the device such as, /dev/vdb. Omit or set this parameter to null for auto-assignment, if supported. If you specify this parameter, the device must not exist in the guest operating system. Note that as of the 12.0.0 Liberty release, the Nova libvirt driver no longer honors a user-supplied device name. This is the same behavior as if the device name parameter is not supplied on the request. | |
| 10:18:50 | stephenfin | lyarwood++ Sweet. I was looking at https://docs.openstack.org/api-ref/compute/?expanded=list-volume-attachments-for-an-instance-detail#list-volume-attachments-for-an-instance and thought it would be mentioned there also | |
| 10:18:55 | stephenfin | once place is good enough though, for sure | |
| 10:19:02 | lyarwood | and I've wanted to remove it entirely from the response but that's going to take reworking the entire attach flow between the API and compute to drop some useless RPC stuff | |
| 10:19:28 | lyarwood | tbh we could also list it in the GET docs | |
| 10:20:25 | sean-k-mooney[m] | stephenfin: so ya i dont think we should have the volume attaments api we have currently and i dont think we should mirror that for the manilla shares going forward | |
| 10:22:55 | lyarwood | sean-k-mooney: I've updated the manila spec FWIW | |
| 10:23:08 | sean-k-mooney[m] | just opened it | |
| 10:23:17 | sean-k-mooney[m] | ill review it this morning | |
| 10:23:51 | sean-k-mooney[m] | i have a doctors appointment in an hour so i might loop back with you later | |
| 10:24:04 | sean-k-mooney[m] | did you see my comment regarding the vm memory | |
| 10:25:05 | sean-k-mooney[m] | oh you going to require file backed memory i almost feel like -2 for that | |
| 10:25:11 | lyarwood | yeah I've suggested going with the simple option for now and queuing the image property work for later on | |
| 10:25:21 | lyarwood | sure go ahead | |
| 10:25:29 | sean-k-mooney[m] | requireing hugepages i could live with | |
| 10:25:46 | sean-k-mooney[m] | file backed memory is not somethign we can schdule on today | |
| 10:26:28 | sean-k-mooney[m] | so there is no way to enforce it so the vm will just not be able to access the shares if it lands on a host without it | |