Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-03
08:00:56 bauzas I know my free.fr ISP is having some problems
08:01:15 gibi I can forward it. should I try it to free.fr or your work mail address?
08:01:52 bauzas saw your reply to Sarah
08:02:40 bauzas confirmed, nothing got received.
08:03:10 bauzas I should ask Sarah whether she got a bot reply
08:03:25 bauzas thanks gibi for the notice
08:03:43 gibi OK, cool
08:09:03 chayan Hi everyone I recently joined the project and am looking for some beginner friendly issues to contribute to can you please help me ?
08:10:49 kashyap chayan: Hi, have you come acros this document yet? - https://docs.openstack.org/nova/latest/contributor/index.html
08:11:56 kashyap chayan: Are you familiar with Gerrit workflow? If not, you might want to check out the sandbox: https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html
08:11:57 bauzas chayan: welcome
08:12:12 bauzas chayan: what kashyap said is a good starting point
08:12:28 kashyap And also this URL: https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html
08:12:40 bauzas you would also want to familiarize with our code repository and all the managed services before going further
08:13:46 chayan sure, thanks kashyap and bauzas :) let me have a look
08:14:56 bauzas chayan: do you have any experience of OpenStack as an operator or player of its APIs, maybe ?
08:15:27 chayan no I do not have experience
08:16:40 chayan I have preliminary knowledge of python and was searching for python projects to contribute to ..... and came accross open stack
08:18:15 bauzas this then will be a challenging but interesting experience :)
08:19:49 chayan sure :) ..... Is there any design document which tells what openstack is ..... I was not able to understand much about it
08:20:02 bauzas chayan: as a starting point, I can't just but emphasize again the need for you to understand our tenets, including the different OpenStack service projects, and then within each of them, their distributed model
08:20:16 bauzas chayan: Nova is one of the many projects that OpenStack has
08:20:53 bauzas chayan: general onboarding docs are better if you directy look at our main OpenStack documentation and not the Nova project itself
08:21:00 bauzas sec, finding you some links
08:21:44 chayan sure
08:22:54 bauzas chayan: Upstream Institute is a good entrypoint https://docs.openstack.org/upstream-training/
08:23:22 bauzas but this won't really dig into the architecture details
08:24:06 bauzas we also have a slidedeck named OpenStack 101 https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-assets-prod/marketing/OpenStack-101-Modular-Deck-1.pptx
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.)

Earlier   Later