| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-28 | |||
| 16:49:40 | dansmith | mriedem said he would go through the hackery in there and see if he could stomach it | |
| 16:49:43 | dansmith | post-haircut Iguess | |
| 16:50:05 | mriedem_away | i got distracted with the DNM debugging earlier | |
| 16:50:13 | dansmith | that's fine, | |
| 16:50:16 | dansmith | I want to see that test run anyway | |
| 16:51:43 | artom | dansmith, I don't like depending on an ordering that's so far away, but maybe we could call it out in a comment in the compute manager, and lest _test_pci() do its thing | |
| 16:51:48 | artom | *let | |
| 16:52:11 | dansmith | artom: can you just remove the other accounting and rely on this one? | |
| 16:52:30 | dansmith | I mean, I don't want to go all into refactoring it, just curious | |
| 16:52:41 | artom | dansmith, that would be a larger effort to make SRIOV live migration use the move claim | |
| 16:52:43 | dansmith | and yes, not relying on ordering is good, but.. | |
| 16:52:50 | artom | Which should get done, but probably not as part of this series | |
| 16:53:11 | dansmith | I'm not sure I understand why it's any different | |
| 16:53:26 | dansmith | because SRIOV migration is not a different operation, so I would expect you'd still hit all this code and be fine | |
| 16:53:29 | dansmith | but mkay | |
| 16:53:49 | artom | I guess I'm just being overly cautious, and don't want to start a potential rabbit hole at this stage? | |
| 16:53:57 | dansmith | yeah for sure | |
| 16:54:09 | dansmith | just... you said it would work with the current ordering | |
| 16:54:19 | artom | Oh, you mean that? yeah, we could do that | |
| 16:54:26 | dansmith | no, | |
| 16:54:49 | dansmith | I'm taking that to its logical (to me) conclusion | |
| 16:54:50 | dansmith | anyway, | |
| 16:54:51 | dansmith | this is why we really should have been working on this set at the beginning of a cycle and not the end | |
| 16:55:06 | dansmith | so it's frustrating to have to bake in debt like this because of the timeline, | |
| 16:55:09 | artom | Yeah | |
| 16:55:16 | dansmith | especially if you're going to be busy again early next cycle such that it never gets cleaned up | |
| 16:55:51 | artom | I mean, there's no guarantee that we would have stumbled on this earlier, but it's a true thing as a matter of principle, so I can't disagree | |
| 16:56:03 | artom | Anyways, I gotta run for first school day | |
| 16:56:11 | artom | Well, half-day | |
| 16:57:56 | openstackgerrit | Merged openstack/nova master: Add nova.compute.utils.delete_image https://review.opendev.org/637605 | |
| 16:58:06 | openstackgerrit | Merged openstack/nova master: Refactor ComputeManager.remove_volume_connection https://review.opendev.org/642183 | |
| 17:06:29 | spatel | sean-k-mooney: hey!! afternoon | |
| 17:15:02 | donnyd | Do people connect cdrom devices for reasons other than config-drive in most cases? | |
| 17:21:43 | dansmith | mriedem_away: numa flavor got created after my change | |
| 17:25:05 | jroll | so I'm doing GPU passthrough with a few different devices. one of them apparently exposes some SRIOV PFs, so it's presenting as `type-PF` rather than `type-PCI`, and so passthrough isn't working with a `pci_passthrough` property on the flavor. do I need to like, figure out how to do SRIOV and go that route, or is there a way to tell nova to maek it just a regular PCI device? | |
| 17:25:24 | dansmith | mriedem_away: and...failed to boot an instance with it | |
| 18:12:06 | sean-k-mooney | dansmith: Failed to start libvirt guest: libvirtError: Requested operation is not valid: cpu affinity is not supported | |
| 18:12:42 | sean-k-mooney | <domain type='qemu'> | |
| 18:13:02 | sean-k-mooney | setting the virt_type to kvm did not work | |
| 18:13:57 | sean-k-mooney | yep its set to qemu | |
| 18:13:58 | sean-k-mooney | https://d8076f0c34babfa2d8fa-c3c714f53a28264bde7e35c9b01061ab.ssl.cf2.rackcdn.com/678887/8/check/nova-live-migration/21801ca/logs/etc/nova/nova-cpu.conf.txt.gz | |
| 18:14:06 | sean-k-mooney | which is why the job failed | |
| 18:14:45 | sean-k-mooney | the local.conf has LIBVIRT_TYPE=kvm https://d8076f0c34babfa2d8fa-c3c714f53a28264bde7e35c9b01061ab.ssl.cf2.rackcdn.com/678887/8/check/nova-live-migration/21801ca/logs/local.conf.txt.gz | |
| 18:14:51 | dansmith | sean-k-mooney: cool, gonna push up a change? | |
| 18:15:07 | sean-k-mooney | the issue it seams is its set twice | |
| 18:15:21 | sean-k-mooney | yes ill fix it | |
| 18:15:47 | sean-k-mooney | we just need to set the virt type in the zuul.yaml instead | |
| 18:15:50 | dansmith | maybe we need to set it in the hook and restart compute? | |
| 18:15:56 | dansmith | okay | |
| 18:16:18 | dansmith | er, no the hook won't affect the subnode I guess | |
| 18:16:38 | sean-k-mooney | the base gate jobs hardcode it to qemu but we can just override it | |
| 18:16:50 | dansmith | ack | |
| 18:21:43 | mriedem_away | overriding it is what i did in the run.yaml | |
| 18:22:07 | sean-k-mooney | ya but it didnt work | |
| 18:22:08 | lbragstad | johnthetubaguy any chance you'd be willing to take a peek at https://review.opendev.org/#/c/644615/ ? | |
| 18:22:09 | sean-k-mooney | https://github.com/openstack/devstack/blob/master/.zuul.yaml#L223 | |
| 18:22:12 | sean-k-mooney | im just going to set this | |
| 18:22:14 | mriedem | i removed it from the run_test script b/c it was only setting it on the primary and not the subnode compute as well, but we shouldn't need to do that since it's in local.conf | |
| 18:22:27 | mriedem | sean-k-mooney: yeah, that's what i did in the run.yaml | |
| 18:22:47 | mriedem | sean-k-mooney: https://review.opendev.org/#/c/678887/8/playbooks/legacy/nova-live-migration/run.yaml | |
| 18:22:59 | sean-k-mooney | i didnt think you coudl do it there | |
| 18:23:10 | sean-k-mooney | or rather i hav enever tried too | |
| 18:23:18 | sean-k-mooney | oh ya | |
| 18:23:19 | mriedem | it's the legacy way | |
| 18:23:24 | sean-k-mooney | so it ended up being there twice | |
| 18:23:33 | sean-k-mooney | both with qemu and then with kvm | |
| 18:23:39 | sean-k-mooney | i dont know why qemu | |
| 18:23:42 | sean-k-mooney | won | |
| 18:23:44 | sean-k-mooney | but it did | |
| 18:24:28 | mriedem | yeah, so i guess just overriding in zuul.yaml might work | |
| 18:24:37 | sean-k-mooney | ill set it in all the places | |
| 18:24:43 | sean-k-mooney | one of them will work :) | |
| 18:24:53 | mriedem | i'd say while doing that, also comment out the jobs we don't care about running | |
| 18:25:09 | sean-k-mooney | ya no need to was gate time | |
| 18:25:16 | mriedem | could also just do post-config|$NOVA_CPU_CONF | |
| 18:25:40 | sean-k-mooney | yep | |
| 18:25:46 | mriedem | but i don't really trust that LIBVIRT_TYPE variable | |
| 18:25:53 | sean-k-mooney | i can do that too | |
| 18:26:01 | mriedem | dansmith: so is it worth me looking at https://review.opendev.org/#/c/635669/45 right now? | |
| 18:26:13 | dansmith | yes | |
| 18:32:50 | openstackgerrit | sean mooney proposed openstack/nova master: DNM: Run LM integration tests with NUMA flavor https://review.opendev.org/678887 | |
| 18:33:13 | sean-k-mooney | that is proably over kill but it should for the config to what we want it to have | |
| 18:50:13 | openstackgerrit | sean mooney proposed openstack/nova master: DNM: Run LM integration tests with NUMA flavor https://review.opendev.org/678887 | |
| 18:52:19 | openstackgerrit | sean mooney proposed openstack/nova master: DNM: Run LM integration tests with NUMA flavor https://review.opendev.org/678887 | |
| 19:11:53 | mriedem | dansmith: i've disposed of my soiled diaper | |
| 19:12:53 | dansmith | mriedem: I was looking for confirmation that the hacks to avoid disrupting the sriov stuff would fly with you, which I assume from the summary is ... yes? | |
| 19:13:09 | mriedem | it's definitely better than it was | |
| 19:13:25 | mriedem | being explicit i mean | |
| 19:13:51 | dansmith | yes, but... is that a yes? :) | |
| 19:14:20 | sean-k-mooney | ill redeploy with this version either later today or tomorow and report what i find. | |
| 19:16:06 | dansmith | sean-k-mooney: thanks | |
| 19:22:01 | mriedem | dansmith: well, compared to what? the alternative of making numa live migration miss the release to retrofit the sriov pci claim stuff into the actual MoveClaim? if so, then yes this dirty hackery is acceptable i guess | |
| 19:22:09 | mriedem | i have a feeling it's a hack that we'll have forever | |
| 19:22:12 | mriedem | but such is nova | |
| 19:22:31 | dansmith | yes, that's what I mean, and yes that's the shame I cast on artom earlier this morning about not cleaning it up after the release | |
| 19:22:38 | dansmith | we'll see if the shame works or not | |
| 19:23:04 | melwitt | cast shame 3 | |
| 19:23:18 | melwitt | highest level spell | |
| 19:23:30 | sean-k-mooney | one way or another we will converge them in U | |
| 19:23:31 | mriedem | artom is pretty good at saving throws though | |