Earlier  
Posted Nick Remark
#openstack-nova - 2021-08-06
15:15:50 stephenfin sorry, yes
15:16:05 gibi an added warning works for me
15:16:11 stephenfin actually
15:16:21 stephenfin I have a patch to register options ourselves somewhere
15:16:31 stephenfin wonder can I simply del that option...
15:16:55 stephenfin actually, that won't help the docs generation problem
15:17:02 stephenfin warning it is
15:17:29 gibi ack
15:22:12 opendevreview Sylvain Bauza proposed openstack/nova master: Provide and use other RCs for mdevs if needed https://review.opendev.org/c/openstack/nova/+/803233
15:22:12 opendevreview Sylvain Bauza proposed openstack/nova master: Provide the mdev class for every PCI device https://review.opendev.org/c/openstack/nova/+/802918
15:22:13 opendevreview Sylvain Bauza proposed openstack/nova master: WIP: Cleanup GPU vs. mdev wording https://review.opendev.org/c/openstack/nova/+/803379
15:22:13 opendevreview Sylvain Bauza proposed openstack/nova master: Expose the mdev class https://review.opendev.org/c/openstack/nova/+/801743
15:22:17 bauzas gibi: stephenfin: uploaded latest rev of mdev series due to stephenfin's nits ^
15:22:36 bauzas stephenfin: to make it clear, we accept FOO as a mdev_class option value
15:22:45 bauzas then, we persist FOO in the object set
15:22:52 stephenfin bauzas: okay, what is FOO used for in that case?
15:23:09 stephenfin does it correspond to something on the device or in libvirt?
15:23:14 bauzas but when looking at the mdev_classes, we use the normalize_rc command to provide a CUSTOM_FOO RC name
15:23:17 stephenfin or is it purely used as an identifier?
15:23:36 bauzas that's why we have the helper and why we don't directly return the list of classes
15:23:55 bauzas stephenfin: no, purely an identifier given by the operator
15:24:08 bauzas it could be STEPHENFIN
15:24:08 stephenfin Okay, then why not insist on the CUSTOM_ prefix?
15:24:40 bauzas stephenfin: we could... but we haven't said this in the spec ;)
15:24:48 stephenfin it seems sensible, given this will be used placement
15:25:20 stephenfin I personally would expect my device with mdev_class FOO to use the same value in placement
15:25:24 stephenfin ...if I didn't know better
15:25:27 stephenfin ;)
15:25:52 stephenfin bauzas: does it make sense to you to do that though? We can amend the spec if needed
15:26:16 bauzas well, I wanted to stop working at 5pm :p
15:26:30 bauzas but I could do this this evening
15:26:54 bauzas I need to change a few things but ok
15:27:50 bauzas stephenfin: do you know how to accept an option value to have a specific prefix ?
15:28:02 stephenfin bauzas: like oslo.confg?
15:28:11 bauzas in oslo.config yes
15:28:13 stephenfin I just assumed we'd regex it away
15:28:26 bauzas oh shit you're right
15:28:36 stephenfin i.e. something like (VGPU|CUSTOM_[A-Z_])
15:28:45 stephenfin but more complete
15:28:46 stephenfin :)
15:31:07 zigo bauzas: Hi there ! After a failed migration (mistake in the host ssh keys), I cannot start a GPU instance, it's telling me: "libvirt.libvirtError: internal error: Device 0000:41:00.0 is already in use"
15:31:10 zigo How can I fix this ?
15:31:22 zigo bauzas: I'm asking you because it's an instance with a GPU, as you can see...
15:31:45 bauzas zigo: sorrry, I need to go off
15:31:55 bauzas but looks like you already use the mdev
15:32:02 bauzas in another guest
15:32:06 zigo bauzas: No that's not the case.
15:32:15 zigo It's the only instance of this cloud with a GPU.
15:32:33 zigo (even though we have many available: one per compute)
15:33:11 zigo bauzas: Will you be able to help me later on?
15:33:23 zigo bauzas: It's an instance for Debconf, so it's a good cause ! :)
15:35:12 gibi zigo: bauzas is about to drop of for 3 weeks of PTO in -34 minutes. so your question came just in time :)
15:35:30 zigo Ah, shit ... :)
15:35:36 zigo I'll figure it out, no worries.
15:35:42 zigo bauzas: Have nice holidays !
15:35:51 bauzas and I need to work on stephenfin's concern
15:36:01 gibi zigo: so no other instance is using pci device 0000:41:00.0 on that host?
15:36:09 zigo gibi: Nop.
15:36:17 gibi still libvirt says it is used
15:36:22 stephenfin gibi: I've all but the nova-manage patch of the BW series reviewed. I assume that one can wait a while (it's in merge conflict). Also, melwitt is probably well placed to review that specifically
15:36:46 gibi stephenfin: thanks a lot. I'm still chewing on on your db series.
15:37:07 gibi stephenfin: sure the nova-manage part is the least important and it still misses some test coverage
15:37:34 gibi stephenfin: so you are out next week, will you be back still before the FF?
15:37:47 stephenfin nope, I'm here next week but I'm starting my move the new team
15:37:50 gibi zigo: have you tried to restart libvirtd ?
15:38:00 gibi stephenfin: ohh, then I mixed it
15:38:11 gibi stephenfin: I will be out next week :/
15:38:14 stephenfin I was supposed to be away but things came up
15:38:25 stephenfin I'll still be around for the rest of the cycle but in a reduced capacity
15:38:52 stephenfin so keep reviewing what I've already reviewed and rebasing my own patches, but no new work
15:38:56 gibi stephenfin: OK, I might corner you with some re-review for the packet rate series if needed and you wil see if you have time or not
15:39:05 stephenfin yup, sounds good :)
15:39:17 stephenfin there are two patches with TODOs left that I can see still
15:39:34 gibi zigo: it feels like it is some internal incosistency inside libvirtd
15:40:02 gibi stephenfin: yeah, the ones that needs the neutron counterpart to define the name of the extension
15:43:23 gibi stephenfin: the naming of api_db_api import made me chuckle :) that name well summarizes why naming is one of the hardest thing in programming
15:43:35 stephenfin Yeah :-(
15:43:49 gibi it is sooo historical
15:43:53 stephenfin I tried many alternatives and kept coming back to that
15:44:08 gibi it is not a fault of the current series at all
15:44:28 gibi the current series just distilled it to a well visible name
15:45:00 stephenfin I did considered removing the main DB's 'api' module and folding it in to nova.objects like we did for the API DB, but that was even more work in an already bloated series
15:45:01 stephenfin so...
15:46:13 gibi that api is huge so yeah
15:48:52 gibi it is impressive that you could push through this amount of refactoring in nova
15:54:12 opendevreview Sylvain Bauza proposed openstack/nova master: Provide the mdev class for every PCI device https://review.opendev.org/c/openstack/nova/+/802918
15:54:13 opendevreview Sylvain Bauza proposed openstack/nova master: Expose the mdev class https://review.opendev.org/c/openstack/nova/+/801743
15:54:13 opendevreview Sylvain Bauza proposed openstack/nova master: Provide and use other RCs for mdevs if needed https://review.opendev.org/c/openstack/nova/+/803233
15:54:14 opendevreview Sylvain Bauza proposed openstack/nova master: WIP: Cleanup GPU vs. mdev wording https://review.opendev.org/c/openstack/nova/+/803379
15:54:35 bauzas stephenfin: gibi: last round before I leave : change of the option value to be CUSTOM_ something
15:55:08 bauzas gibi: sorry if I may ask you to review just before you leave, but the changes are femtonits
15:55:20 bauzas I prevented to rebase
15:55:38 bauzas so, PS_n-2 to PS should show the very few differences
15:56:39 stephenfin bauzas: Thanks. I'll start looking now but I will have to leave myself soon enough
15:56:56 stephenfin Worst case scenario, one of us can tweak it while you're away to get it over the line
15:56:56 opendevreview Stephen Finucane proposed openstack/nova master: db: Exclude the 'use_db_reconnect' option https://review.opendev.org/c/openstack/nova/+/803778
15:57:11 stephenfin gibi: ^
15:57:50 stephenfin turns out I _could_ just modify what we were registering since I stopped registering the oslo.db opts in https://review.opendev.org/c/openstack/nova/+/799523/
15:58:02 bauzas stephenfin: I was planning to end at 5pm
15:58:15 bauzas looks like I was on the wrong timezone when I said this

Earlier   Later