| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-01 | |||
| 16:46:41 | giblet | sean-k-mooney: I think I understand. I agree in general to automate it if possible. | |
| 16:47:08 | giblet | sean-k-mooney: I'm more affraid that I will not be able to make it work | |
| 16:47:45 | giblet | stephenfin: alternatively I can remove this patch from the series, declare the two PF on the same compute on the same physnet as not-supported in Stein | |
| 16:47:49 | stephenfin | e.g. confusion with 'devname', issues if you whitelist more than PF and need for extra (possibly unnecessary) configuration, the first two of which probably need additional code to fix | |
| 16:48:33 | stephenfin | giblet: Aye, I was wondering if it was possible to shove this to the end and de-risk it. If that's an option, it might be a good one | |
| 16:48:43 | sean-k-mooney | giblet: i think that is what we did for vgpus | |
| 16:49:18 | sean-k-mooney | its not ideal but it would work. i would be good to ask leakypipes or dansmith | |
| 16:49:32 | sean-k-mooney | they tend to have stong opipions on this topic | |
| 16:50:07 | giblet | stephenfin: yeah, I think the sortness of time will push me to remove this patch from the critical path | |
| 16:50:10 | sean-k-mooney | actully maybe you shouldnt ask them :) | |
| 16:51:45 | sean-k-mooney | giblet: i can try and hack something up at the weekend to do auto tagging and then you can decide on monday | |
| 16:52:46 | giblet | sean-k-mooney: if you hack someting up then I will definitly look at it on Monday but please don't spend your free time on this crazy things :) | |
| 16:54:03 | sean-k-mooney | i spent my free time last weekend trying to autoamte a tox nutika enviorment ot automaticlaly compile nova and then execute the unit test. | |
| 16:54:11 | sean-k-mooney | this might be a less crazy | |
| 16:54:20 | giblet | sean-k-mooney: :) | |
| 16:54:34 | sean-k-mooney | i got it to work for os-vif but nova make it explode | |
| 16:55:44 | leakypipes | sean-k-mooney, stephenfin: ask me what? | |
| 16:56:45 | stephenfin | leakypipes: We're not overly happy about this patch and think pf_interface_name could be figured out dynamically by the driver https://review.openstack.org/#/c/625311/29 | |
| 16:57:21 | sean-k-mooney | noting you will like. unless your opipion on adding tags to the pci whitelist has changed recently | |
| 16:57:31 | stephenfin | leakypipes: giblet is concerned about time constraints though and think maybe declaring that two PF on the same compute on the same physnet as not-supported in Stein would be a safer option | |
| 16:58:05 | stephenfin | *maybe declaring two PFs | |
| 16:58:30 | leakypipes | stephenfin: ok, that patch is near the top of my queue. will try to comment on it this afternoon. | |
| 16:59:11 | giblet | I'm not too affraid of saying that this edge case is not supported in Stein | |
| 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 | |