| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-01 | |||
| 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 | stephenfin | yup. duh | |
| 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: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 | |
| 20:21:48 | mriedem | can't you modify Connection to pass in a hostname which defaults to 'compute1'? | |
| 20:22:18 | mriedem | note that self.start_service() in the tests will allow you to specify the binary (compute) and hostname which is what our multi-host functional tests do, | |
| 20:22:23 | mriedem | but those aren't using the fakelibvirt stuff | |
| 20:23:41 | temka | mriedem, it's solved in the fake virt driver, but that's different because it's a virt drive | |
| 20:24:00 | temka | fakelibvirt isn't a driver - the real libvirt is the driver | |
| 20:24:17 | temka | fakelibvirt just mocks out the parts that call the libvirt API | |