| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-01 | |||
| 16:59:12 | sean-k-mooney | we are already doing auto discovery of nic offloads exctra on startup and we have code to discover the name of pf form vfs in os-vif so i was suggesing just looking up the pf name on startup as part of the pci device discovery | |
| 17:01:42 | giblet | however I will only be able to declare this case unsupported in the documentation as I don't see an easy way to detect the case from code and reject or just fail the boot request | |
| 17:02:26 | giblet | so if the admin ignores the doc then she can create a situation when the bandwidth is allocated from a PF while the VF is allocated from other PF for the same port | |
| 17:04:13 | stephenfin | giblet: Is there a file missing from https://review.openstack.org/#/c/623543/ ? | |
| 17:04:48 | stephenfin | I'm trying to figure out where "Then the pci claim will enforce that the PF interface name in the request matches the interface name of the PF from where the VF is selected from." happens | |
| 17:04:56 | stephenfin | (from the commit message, line 53) | |
| 17:05:21 | giblet | stephenfin: I think the pci claim matches the request with the device spec field by field | |
| 17:05:25 | stephenfin | Oh, wait, tags | |
| 17:05:36 | giblet | so if the pf_interface_name is in the request as well as in the device spec then it will be matched | |
| 17:05:36 | stephenfin | yup. duh | |
| 17:05:40 | stephenfin | It's clearly Friday :) | |
| 17:05:45 | giblet | soo Friday | |
| 17:06:41 | sean-k-mooney | https://www.youtube.com/watch?v=kfVsfOSbJY0 | |
| 17:07:03 | sean-k-mooney | its stuck in my head so i give it to you too | |
| 17:11:23 | giblet | it is heavy stuff :) | |
| 17:20:52 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/636699 | |
| 17:20:53 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: Remove TypeError handling for get_info https://review.openstack.org/640043 | |
| 17:25:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206 | |
| 17:28:11 | mriedem | bauzas: i'm good with ^ again | |
| 17:28:21 | mriedem | we should all thank avolkov for his persistence | |
| 17:41:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: explain aggregate set_metadata semantics https://review.openstack.org/640460 | |
| 17:44:42 | mriedem | stephenfin: cfriesen: can one of you backport https://review.openstack.org/#/c/635350/ to stable/rocky? | |
| 17:44:58 | cfriesen | mriedem: can do | |
| 17:45:01 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: fix up numa-topology live migration hypervisor check https://review.openstack.org/640462 | |
| 17:45:05 | cfriesen | okay | |
| 17:45:09 | cfriesen | :) | |
| 17:45:19 | stephenfin | no merge conflicts :) | |
| 17:46:35 | temka | stephenfin, hey, sean-k-mooney's saying on the mailing list that you somehow managed to get different configs to different services in func tests. Any recollection of that? | |
| 17:46:56 | stephenfin | ummm... | |
| 17:47:00 | temka | (No link to ML post because the web UI is apparently lagging behind) | |
| 17:47:25 | temka | stephenfin, I'm normally artom, btw, in case you're wondering | |
| 17:49:03 | stephenfin | temka: I'm _guessing_ he's referring to 45662d77a2da77714f8e792e86ebd64a52270ef5 | |
| 17:50:44 | stephenfin | temka: I don't think it's possible to have different nova.conf configurations in functional tests though | |
| 17:51:24 | temka | (Okay, turns out this friday nick idea wasn't necessarily the best, because 'temka' is normally what my mom calls me) | |
| 17:51:27 | stephenfin | that config is global so as soon as you'd change it, every service would see the change | |
| 17:51:42 | temka | stephenfin, that's what I thought | |
| 17:54:33 | aspiers | melwitt, mriedem: if we are retargeting SEV for Train, what is the correct approach to updating the spec/bp? | |
| 17:55:06 | mriedem | https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications | |
| 17:55:24 | aspiers | hah, sorry - still asking newbie FAQs :) | |
| 17:55:51 | aspiers | breton: ^^^ | |
| 18:20:09 | openstackgerrit | Adam Spiers proposed openstack/nova master: fix bug with XML matcher handling missing children https://review.openstack.org/640411 | |
| 18:28:35 | openstackgerrit | Adam Spiers proposed openstack/nova master: Parse |
|
| 19:06:41 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.openstack.org/633855 | |
| 19:15:41 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.openstack.org/633855 | |
| 19:17:19 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver https://review.openstack.org/638680 | |
| 19:27:05 | openstackgerrit | Merged openstack/python-novaclient master: Remove unnecessary if statement https://review.openstack.org/640266 | |
| 19:27:56 | temka | aspiers, btw, going by your commit message in https://review.openstack.org/#/c/638680/4, you know you can submit multiple patches as a stack/series for review, right? | |
| 19:28:39 | aspiers | temka: that's what I've done :) | |
| 19:29:00 | temka | aspiers, ok cool - you were calling out a dependency needlessly in your commit message, so I wanted to double check | |
| 19:29:22 | aspiers | temka: well, I don't think it's entirely needless. I think it helps explain the dependency | |
| 19:29:43 | temka | aspiers, as you wish :) | |
| 19:29:54 | aspiers | I'm a believer in "too much info is better than not enough" - at least in this context | |
| 19:30:09 | temka | I'm not sure I'd agree, actually :) | |
| 19:30:18 | aspiers | not in general | |
| 19:30:26 | temka | Heh, not even in this context | |
| 19:30:32 | aspiers | It's easier for reviewers to skip over stuff which is obvious to them than for them to be forced to figure out non-obvious stuff | |
| 19:30:45 | aspiers | The former is quicker than the latter | |
| 19:30:56 | aspiers | I'm generalizing, of course :) | |
| 19:31:08 | temka | For me at least, it implies that there's a dependencies that's not already apparent in the patch series | |
| 19:31:09 | aspiers | but I think it's true in this particular scenario | |
| 19:31:18 | temka | So I went looking, and realized you were just making it really explicit | |
| 19:31:53 | aspiers | The thing is, a patch series is linear, but a dependency tree is a DAG | |
| 19:32:15 | aspiers | The serialization is lossy, so it is not trivial to infer the tree from the series | |
| 19:32:41 | temka | Heh | |
| 19:32:44 | aspiers | Coincidentally, I've done a lot of work on this topic outside OpenStack: https://github.com/aspiers/git-deps | |
| 19:33:21 | aspiers | But anyway, I welcome all nitpicks, so thanks ;-) | |
| 19:33:54 | temka | aspiers, heh, I can't bring myself to concentrate fully on what I'm trying to do, so instead I nitpick others's work :/ | |
| 19:34:07 | aspiers | LOL I have exactly the same problem ;-) | |
| 19:34:23 | temka | I had no idea of your level of experience with Gerrit, so just wanted to make sure you're not pushing one patch at a time and manually specified the deps | |
| 19:35:00 | aspiers | temka: Yeah thanks, it's definitely worth checking that with unfamiliar faces^Wnicks :-) | |
| 19:35:37 | aspiers | I'm pretty familiar with Gerrit. Attended the last User Summit which was super fun and interesting. | |
| 19:35:57 | temka | But then you started talking about DAGs and I realized I'm *probably* barking up the wrong tree ;) | |
| 19:36:04 | aspiers | ;) | |
| 19:36:31 | temka | Mind you, I've seen people graduate with CS degress and not be able to write a single line of C, so :P | |
| 19:36:38 | aspiers | This is true | |
| 19:36:58 | aspiers | git and its ecosystem is actually one of my specialist areas | |
| 19:38:29 | aspiers | I've hacked on git a bit, and built a plethora of tools. Since it's Friday, you can find more ramblings at https://blog.adamspiers.org/tag/git/ if you're curious | |
| 19:38:50 | temka | "Structured Procrastination" | |
| 19:38:52 | temka | Sounds about right | |
| 19:39:13 | aspiers | Also will finish adding https://ethercalc.openstack.org/github-gerrit to the Contributor's Guide one of these days ... maybe :-o | |
| 19:41:16 | temka | aspiers, wanna add https://github.com/berrange/gerrymander in the Gerrit clients square? | |
| 19:41:31 | aspiers | ooh, that's a new one for me I think | |
| 19:41:35 | aspiers | temka: please feel free | |
| 19:42:05 | temka | Not sure it's still maintained, it's been a few years since last commit | |
| 19:43:21 | aspiers | add it anyway | |
| 19:43:25 | temka | Done | |
| 19:44:47 | aspiers | mriedem: SEV trait successfully detected on real hardware using capabilities :) https://pasteboard.co/I3rPhvJ.png | |
| 19:52:43 | mriedem | get right out of town | |
| 19:52:50 | aspiers | :) | |
| 19:53:25 | aspiers | plus all those new capability traits too of course | |
| 19:57:16 | mriedem | aspiers: so you've already worked around the virConnectGetDomainCapabilities thing? | |
| 19:57:25 | cfriesen | sean-k-mooney: ran into a problem with the cold migration with TPM.../var/lib/libvirt/swtpm and the directories under it are owned by root and nova-compute is not running as root. | |
| 19:57:58 | aspiers | mriedem: yes, https://review.openstack.org/#/c/633855/7/nova/virt/libvirt/host.py@711 | |
| 19:58:57 | aspiers | mriedem: for SEV, this is *almost* good enough for now; I think the only possible issue is that if testing on another distro, qemu-kvm might live in a different place | |
| 19:59:14 | aspiers | I don't have a RHEL / Fedora box handy to check | |
| 20:00:19 | aspiers | mriedem: and the code in comments is pretty darn close to what it will look like when that patch does land | |
| 20:19:55 | temka | Dammit, even something as simple as 2 different hostnames for the 2 compute services is going to be annoying | |
| 20:20:34 | temka | https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/fakelibvirt.py#L1131 | |
| 20:20:42 | mriedem | melwitt: i'm confused about your comment here https://review.openstack.org/#/c/633350/7/nova/objects/instance_mapping.py@42 | |
| 20:21:20 | mriedem | temka: ah that's where that comes from...i was wondering because that question came up in a functional test that gibi wrote which was using the fakelibvirt stuff | |