| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-03 | |||
| 08:25:51 | bauzas | and we also had a book which becomes a bit stale (last update is 2017) but can still be relevant for getting the overall idea https://docs.openstack.org/operations-guide/ | |
| 08:27:22 | bauzas | HTH | |
| 08:29:25 | chayan | yeah I went through the slides | |
| 08:30:01 | chayan | I think the links will be helpful... thanks | |
| 08:48:43 | songwenping_ | gibi: shall we put the pre-filter of owner_nova trait request to flavor? | |
| 08:50:06 | gibi | songwenping_: hi! sorry I don't understand the question. do you have a patch or other context I can look at? | |
| 08:52:15 | songwenping_ | oh, i'm sorry. the question is for the owner_nova trait usage spec:https://review.opendev.org/c/openstack/nova-specs/+/819510 | |
| 08:53:18 | songwenping_ | about the work item 3:Add pre-filter the trait for every Nova request group. | |
| 08:53:52 | gibi | songwenping_: ohh I see now. | |
| 08:54:35 | gibi | songwenping_: so what we really want is to add it to every request group that was create due to the flavor yes | |
| 08:55:33 | gibi | including the unnamed group containing the CPU and memory request, and including the group requesting GPU due to GPU was requested via the flavor | |
| 08:55:58 | gibi | but not including the group that was created from a neutron port, or from a cyborg resource request | |
| 08:58:28 | songwenping_ | so we should add 'owner_trait=nova' with pci_passthrough for the flavor property? | |
| 09:08:25 | gibi | I don't think the admin should add the trait manually to the flavor. I think nova should automatically add the trait to the request groups it creates | |
| 09:10:09 | songwenping_ | gibi: if flavor doesnot have the property, how do we check the compute minimum version? | |
| 09:13:22 | gibi | songwenping_: you can call service_obj.get_minimum_version_all_cells( context, ["nova-compute"]) | |
| 09:13:36 | gibi | to determine the global minimum of compute service versions | |
| 09:14:06 | gibi | but probably the current prefilter interface is not good to determine where the add the traits | |
| 09:15:12 | songwenping_ | yes, i'm wondering where to add the traits and check the version | |
| 09:17:05 | gibi | so prefilter runs on RequestSpec objects, but some of the flavor induced placement RequestGroups are create after the prefilters were run in the call of nova.scheduler.utils.ResourceRequest.from_request_spec | |
| 09:20:34 | gibi | songwenping_: you can try to think about changing ResourceRequest.from_request_spec and make RequestGroup creation explicit there | |
| 09:21:18 | songwenping_ | gibi: ok, thanks. | |
| 09:22:54 | gibi | songwenping_: currently nova.scheduler.utils.ResourceRequest._add_resource implicitly creates a new group if it is not exists | |
| 09:24:40 | gibi | songwenping_: feel free to propose a WIP patch playing with this idea and we can involve others to look at the problem and offer ideas | |
| 09:25:01 | gibi | I do thing that a pure prefilter will wont work due to some code structural challenges | |
| 09:25:38 | gibi | *think | |
| 09:25:42 | songwenping_ | ok thanks. i'll try to research. | |
| 09:25:46 | gibi | cool | |
| 11:17:53 | zigo | Hi there! I have a problem with live migrations: | |
| 11:17:53 | zigo | Live Migration failure: operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.103.4/system: authentication failed: Failed to verify peer's certificate: libvirt.libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.103.4/system: authentication failed: Failed to verify peer's certificate | |
| 11:17:53 | zigo | How comes libvirt / qemu tries to connect using the *IP ADDRESS* rather than the *HOSTNAME* which makes my PKI fail? | |
| 11:17:59 | zigo | Is there a way to fix that? | |
| 11:18:40 | sean-k-mooney | there is a config option for this i think | |
| 11:18:50 | zigo | sean-k-mooney: In where? In Nova ? | |
| 11:19:01 | sean-k-mooney | yes | |
| 11:19:38 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_inbound_addr and https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_uri | |
| 11:20:24 | sean-k-mooney | zigo: im guessing you have live_migration_inbound_addr set | |
| 11:20:27 | zigo | I already have live_migration_uri=qemu+tls://%s/system ... | |
| 11:20:50 | zigo | Oh, I do... | |
| 11:20:52 | sean-k-mooney | right but if you have live_migration_inbound_addr it will result in the ip | |
| 11:21:02 | zigo | sean-k-mooney: So I should remove that? | |
| 11:21:11 | zigo | Or set this as hostname instead ? | |
| 11:21:26 | sean-k-mooney | if you remove it it will use the hostname by default | |
| 11:21:45 | sean-k-mooney | it depens on if you are setting live_migration_inbound_addr to choose which interface is used to copy the vm data or not | |
| 11:21:55 | zigo | It's more complicated for me, maybe puppet is doing this by default, let's see if I can convince it to use hostnames instead. Thanks a lot ! | |
| 11:22:29 | sean-k-mooney | live_migration_inbound_addr is normally used to baically for which interface is used but you can do that via dns also | |
| 11:23:59 | zigo | I have all of my cluster defined in /etc/hosts ! :) | |
| 11:24:13 | sean-k-mooney | hehe ya i like to do that too | |
| 11:24:22 | zigo | Production experience showed me that my colleague's DNS service sometimes fail ... :P | |
| 11:29:37 | zigo | This fixed the problem, though now I get: | |
| 11:29:37 | zigo | Live Migration failure: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory: libvirt.libvirtError: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory | |
| 11:29:45 | zigo | Weird, I didn't use to have this before ... :/ | |
| 11:30:03 | zigo | Is this the same as /etc/pki/CA/cacert.pem ? | |
| 11:31:55 | sean-k-mooney | i dont think so. i do know that more recent versions of libvirt/qemu change the behaivor slightly no you need both a clien tan dserver cert or something like that | |
| 11:32:20 | sean-k-mooney | in ooo we just symlinked the server fiels to the client folder | |
| 11:32:22 | zigo | Yeah, that I know. Client + server cert. | |
| 11:32:29 | zigo | That's what I'm trying to do. | |
| 11:33:18 | sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1957152 i think this was the downstream bug | |
| 11:36:15 | sean-k-mooney | it looks like they just hardcoded the path to /etc/ipa/ca.crt | |
| 11:36:16 | sean-k-mooney | https://review.opendev.org/c/openstack/tripleo-heat-templates/+/796673/1/deployment/nova/nova-libvirt-container-puppet.yaml | |
| 11:38:33 | zigo | It's full of red hat - ism ... The /etc/pki folder should have been renamed to something else in Debian based systems, like /etc/ssl/<something> or /etc/libvirt ... | |
| 11:39:04 | zigo | I don't think I have the /etc/ipa yet though. | |
| 11:40:02 | sean-k-mooney | thats not surprising | |
| 13:21:47 | artom | zigo, sean-k-mooney, yeah, we currently have 2 trackers open for something very similar | |
| 13:22:25 | artom | https://bugs.launchpad.net/tripleo/+bug/1959328 in upstream TripleO | |
| 13:22:36 | artom | And https://bugzilla.redhat.com/show_bug.cgi?id=2079767 for our downstream product | |
| 13:23:16 | artom | What's weird is that those are very TripleO-specific | |
| 13:23:33 | artom | So I wouldn't think they affect any other deployment means | |
| 13:27:09 | sean-k-mooney | artom: i think its because of the reuse of puppet | |
| 13:38:12 | opendevreview | Rico Lin proposed openstack/nova-specs master: Add IOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | |
| 13:40:58 | kashyap | gibi: artom: Can you re-look at this, pls - https://review.opendev.org/c/openstack/nova/+/838926 (Add a workaround to skip compareCPU() on destination) | |
| 13:41:07 | kashyap | (When you get a moment, i.e.) | |
| 13:41:34 | gibi | kashyap: will look | |
| 13:42:17 | sean-k-mooney | artom: in principal the openstack pupet modules are ment to be multi distro and also not ooo specific but because of redhats in vovlement in them that is not always the case | |
| 13:46:09 | kashyap | No one is stopping other distros to add support for it | |
| 13:46:29 | kashyap | sean-k-mooney: On the flip side, sometimes RHT folks do plenty work for other distros too. (All in good faith) | |
| 13:47:26 | kashyap | My general point is, we should not expect any one distro vendor to do the enablement work for other distros | |
| 13:47:32 | kashyap | (Modulo exceptions) | |
| 13:47:45 | artom | kashyap, done | |
| 13:49:13 | kashyap | Thx; will look | |
| 13:50:45 | kashyap | artom: On double-negation, I agree in general. But in this case, IMO the "skip" wording is more explicit. And it isn't _that_ big of a cognitive burden :) | |
| 13:51:12 | gibi | kashyap: done too, I have no blocking issue just a question about deprecation of the config option | |
| 13:51:37 | artom | kashyap, yeah, it's not a hill I'm going to die on, but I wanted to raise the point | |
| 13:51:46 | kashyap | artom: Yeah, fair point for sure | |
| 13:52:10 | kashyap | gibi: Yeah, good point on deprecation. I'll think a bit more on it | |
| 13:52:16 | kashyap | Will answer there. Thx, both | |
| 13:56:03 | chayan | Hi everyone, I have python knowledge but do not have a cs background .....can you give me an idea of which cs topics/subject or others may be pre requisites for understanding the openstack-nova project? thanks | |
| 13:59:24 | opendevreview | ribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova-specs/+/831506 | |
| 14:13:11 | opendevreview | Artom Lifshitz proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 14:21:37 | kashyap | chayan: One area coulbe to to understand how virtual machines are configured (particularly KVM, QEMU, or even other "hypervisors" like Xen, etc) | |
| 14:25:09 | kashyap | chayan: Also please look at the links we (including bauzas) have posted already earlier in the day. (The contributor, getting started, etc docs) | |
| 14:25:56 | chayan | sure thanks a lot for the help ... I am already going through the links you guys gave me ... thanks again | |
| 14:35:41 | opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add a workaround to skip compareCPU() on destination https://review.opendev.org/c/openstack/nova/+/838926 | |
| 14:35:48 | kashyap | artom: gibi: Fixed --^ | |
| 14:41:16 | gibi | Uggla: commented on the Manial spec. thanks for the state diagram, it helped me to ask more questions :) | |
| 14:42:13 | Uggla | gibi, not sure this is a good news for me. :) | |
| 14:42:40 | artom | Questions are good :) | |
| 14:44:35 | opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 14:45:01 | Uggla | gibi, btw I have just done a slight update. | |
| 14:58:00 | gibi | ack | |