| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-10 | |||
| 17:00:10 | elodilles | bauzas: i know it's spec review day, but... o:) maybe these worth some quick reviews (perhaps tomorrow :)): https://review.opendev.org/q/Ieba7daf39fa3323e8c9a7396747449f24189fcd5 | |
| 17:00:38 | bauzas | joys of May and my number of PTO days which is too high for the end of the paperwork year | |
| 17:00:40 | elodilles | bauzas: or if you'll be on PTO then the day after your PTO :X | |
| 17:01:08 | bauzas | I may have to take more PTO days before end of May, but I'll restrict myself to one per week | |
| 17:01:26 | sean-k-mooney | i can hit the master patch | |
| 17:01:38 | elodilles | sean-k-mooney: awesome, thanks! \o/ | |
| 17:02:03 | bauzas | done | |
| 17:02:16 | elodilles | thanks \o/ | |
| 17:03:21 | sean-k-mooney | elodilles: are there any other "nova" repos these are still pending for | |
| 17:03:28 | sean-k-mooney | i think we already did some of them | |
| 17:03:55 | elodilles | sean-k-mooney: to tell you the truth i don't know. maybe os-vif also have l-c? | |
| 17:04:13 | sean-k-mooney | it did but i think i approve the removal already | |
| 17:04:34 | sean-k-mooney | yep if anyone want to be the second +2 https://review.opendev.org/c/openstack/os-vif/+/840020 | |
| 17:04:57 | sean-k-mooney | or i can just merge this with a singel +2 if peopel dont revew by the end of the week | |
| 17:05:42 | sean-k-mooney | ah nova itself | |
| 17:05:54 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/840021 | |
| 17:06:49 | elodilles | yepp, in nova i started with stable-only patches as stable branches were blocked | |
| 17:07:13 | elodilles | so, nice catch sean-k-mooney :) | |
| 17:07:26 | sean-k-mooney | stephenfin: ^ care to take a look at the nova and os-vif lc patches | |
| 17:07:33 | elodilles | those are still waiting for some reviews :X | |
| 17:08:15 | stephenfin | sure | |
| 17:17:01 | sean-k-mooney | ok im going to call it a day | |
| 17:19:50 | gibi | artom: thanks for the bug triage! | |
| 17:24:28 | artom | gibi, happy to help :) | |
| 17:28:16 | melwitt | bauzas: I added a note about optionalness of etherpads/docs https://etherpad.opendev.org/p/nova-bug-triage-roster feel free to change it or remove it or whatever | |
| 18:15:42 | opendevreview | Merged openstack/placement master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840018 | |
| 18:44:28 | donny | Hi everyone I recently joined the project and would like to contribute....can someone please help me on how to go about understanding the codebase | |
| 19:55:12 | opendevreview | Merged openstack/placement stable/yoga: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840728 | |
| 21:48:16 | opendevreview | Merged openstack/placement stable/xena: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840756 | |
| 22:14:07 | opendevreview | Miguel Lavalle proposed openstack/os-vif master: Revert "Fix race with DPDK and vhostuserclient mode" https://review.opendev.org/c/openstack/os-vif/+/841276 | |
| 22:18:02 | opendevreview | Miguel Lavalle proposed openstack/os-vif master: Revert "Fix race with DPDK and vhostuserclient mode" https://review.opendev.org/c/openstack/os-vif/+/841276 | |
| #openstack-nova - 2022-05-11 | |||
| 03:15:47 | donny | Hi everyone I recently joined the project and would like to contribute....can someone please help me on how to go about understanding the codebase | |
| 09:06:51 | kashyap | gibi: Have you seen this one before: https://zuul.opendev.org/t/openstack/build/ab5025372ff34fdf99180efe049de5cd | |
| 09:07:02 | kashyap | rsync: [sender] change_dir "/var/lib/zuul/builds/ab5025372ff34fdf99180efe049de5cd/work/CA" failed: No such file or directory (2) | |
| 09:10:52 | kashyap | (Aside: The 'py310' 'mysqld' error was solved by your bindep.txt change: https://review.opendev.org/c/openstack/nova/+/840822) | |
| 09:13:41 | gibi | kashyap: I think there is another error before that | |
| 09:13:55 | gibi | https://zuul.opendev.org/t/openstack/build/ab5025372ff34fdf99180efe049de5cd/log/job-output.txt#24628 | |
| 09:14:12 | gibi | rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]\nrsync error: unexplained error (code 255) at io.c(228) [Receiver=3.2.3 | |
| 09:15:01 | kashyap | Oh, yeah. Amazing, how the error itself says "unexplained error" | |
| 09:20:19 | gibi | btw, I haven't find any other similar failure in the past week | |
| 09:20:31 | gibi | so I assume this is an intermittent network failure | |
| 12:10:22 | opendevreview | Rajat Dhasmana proposed openstack/nova-specs master: Repropose volume backed server rebuild spec https://review.opendev.org/c/openstack/nova-specs/+/840155 | |
| 13:10:48 | opendevreview | ribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova-specs/+/831506 | |
| 13:16:03 | kashyap | gibi: (Sorry, wasn't looking here.) So, given the above rsync error seems intermittent. Can I recheck with "recheck intermittent rsync error"? | |
| 13:16:11 | kashyap | I want to be careful w/ rechecks | |
| 13:17:37 | gibi | kashyap: yes, I can even paste my query to show that there is no other similar hits recently... give me a sec | |
| 13:19:00 | kashyap | Heh, I'll believe you. Thanks! | |
| 13:19:54 | gibi | kashyap: done, I've rechecked it with some proof that it is not something we want to care about right now | |
| 13:22:33 | kashyap | gibi: Kösz! | |
| 13:22:33 | kashyap | gibi: Kösz! | |
| 13:22:40 | gibi | nincs mit :) | |
| 15:06:11 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Reproduce bug 1896463 in func env https://review.opendev.org/c/openstack/nova/+/841288 | |
| 15:30:22 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Set instance host and drop migration under lock https://review.opendev.org/c/openstack/nova/+/841444 | |
| 16:29:20 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Reproduce bug 1896463 in func env https://review.opendev.org/c/openstack/nova/+/841288 | |
| 16:29:21 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Set instance host and drop migration under lock https://review.opendev.org/c/openstack/nova/+/841444 | |
| 16:50:10 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Set instance host and drop migration under lock https://review.opendev.org/c/openstack/nova/+/841444 | |
| 17:29:57 | opendevreview | Rico Lin proposed openstack/nova-specs master: Add vIOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | |
| 17:32:26 | ricolin | gibi: sean-k-mooney just update viommu spec, please kindly review again :) | |
| 17:39:25 | sean-k-mooney | thanks ill likely be finsihing soon but ill revew again tomorrow | |
| 18:30:00 | mnaser | i will start with: this is a terrible idea | |
| 18:30:41 | mnaser | but somehow, i've got a weird requirement where a vm needs have a mapping of the pci address on the host device <=> pci address on the vm | |
| 18:31:17 | mnaser | i know pci_devices in the db contains what is assigned to what, but i dont think it contains what is the guest addres.. and i think we're relying on libvirt to maintain that sort of thing, right? | |
| 18:32:56 | dansmith | I'm not sure, but I'm curious what kind of application has this requirement :) | |
| 18:34:12 | dansmith | and to be clear, you mean the guest needs to know what the host's address of a pci device is (since it clearly knows its own mapping)? | |
| 18:34:14 | mnaser | dansmith: accelerator cards that need to be setup in a specific topology, and it seems that the the vm needs to know which card is which | |
| 18:34:54 | mnaser | yep | |
| 18:35:03 | dansmith | meaning I got two gpus and I need to know which one is "first" on the host? | |
| 18:35:24 | mnaser | Yes, something like that | |
| 18:35:51 | dansmith | I think exposing the actual host address is a bad idea, but maybe the ordering wouldn't be so bad (although really odd) | |
| 18:36:16 | mnaser | I think it’s a bad idea too but it seems that the cards somehow communicate | |
| 18:36:29 | mnaser | So as part of their topology setup, they need to know where the other one is | |
| 18:36:42 | dansmith | ...which seems like asking for a hardware-assisted vulnerability, but whatevs | |
| 18:36:53 | mnaser | You’re not wrong :/ | |
| 18:37:48 | mnaser | dansmith: we’ll from what I understand they just want to know which card is attached from the system .. like is it card 1 or card 2 or card 5 | |
| 18:37:53 | dansmith | how is it that crazy composable hardware people want to make boxes that can re-assign dimms between logical systems, but accelerator people can't build things that don't require knowing the address of the other one? | |
| 18:37:57 | dansmith | nevermind, don't answer that | |
| 18:38:19 | mnaser | And since the pci address is the “stable” way of knowing which one is which | |
| 18:38:45 | dansmith | mnaser: right, so what I was saying is knowing "this is the 3rd card of type 8086:abcd in the host system" would be enough? | |
| 18:39:35 | mnaser | dansmith: I believe so yes | |
| 18:39:53 | dansmith | that'd be the only thing I could imagine reasonably supporting | |
| 18:40:06 | dansmith | and off by default because.. seriously. | |
| 18:40:22 | mnaser | oh yes I don’t even expect this to be in nova at all cause I think this is silly. | |
| 18:40:33 | dansmith | even better :) | |
| 18:41:05 | dansmith | sorting the devices we attach to the guest so that they're in the same logical order as on the host might not be too bad either I guess | |
| 18:41:09 | mnaser | I was mainly wondering if there’s somewhere I can scrape this info and plumb into vendor metadata | |
| 18:41:15 | dansmith | like "if you're going to get two of these, make sure they're in the same order" | |
| 18:41:30 | mnaser | Yeah it seems at random right now | |
| 18:41:46 | dansmith | well, once is the guest is running I expect you can see it in the libvirt xml | |
| 18:42:13 | mnaser | Yeah so the idea was that using vendor metadata 2 (with the proxy) and then doing terrible things to pull that info in | |
| 18:43:29 | dansmith | yeah I like that because the "terrible things" are yours and you get to own them :P | |
| 18:46:01 | melwitt | mnaser: this sounds like device tagging, will that not work for this? | |
| 18:46:37 | mnaser | dansmith: I recognize the pain of maintaining said terrible things | |
| 18:46:44 | mnaser | melwitt: lemme see | |
| 18:46:56 | mnaser | (Never heard/used) | |
| 18:47:04 | melwitt | trying to find a doc | |
| 18:47:28 | melwitt | https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html | |
| 18:47:56 | dansmith | melwitt: device tagging lets you tag the thing you requested, but since you don't control which one you got of two identical types, I don't think it will | |
| 18:48:17 | dansmith | tagging might make it easier to line them up and expose them in metadata though | |
| 18:49:47 | mnaser | melwitt: yeah it looks like it doesn’t talk much about tagging pci pass through as well | |
| 18:50:18 | dansmith | I think you can tag pci now, but I still think it doesn't help | |