| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 22:01:37 | openstackgerrit | Eric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates https://review.opendev.org/671075 | |
| 22:01:37 | openstackgerrit | Eric Fried proposed openstack/nova master: Docs for isolated aggregates request filter https://review.opendev.org/667952 | |
| 22:02:00 | fungi | given the expectation is that if the change has made it through check then it normally shouldn't fail in the gate either, so as soon as one failure is encountered it can just be reported and ejected | |
| 22:02:13 | efried | like that one --^ | |
| 22:02:22 | sean-k-mooney | fungi: isnet there a way to make jobs depend on other jobs in the same pipline | |
| 22:02:45 | fungi | there is, but then you delay starting them until the others finish which increases time to report on success | |
| 22:03:12 | sean-k-mooney | yes but if you only dely it by the 5-10 minute fo the tox jobs | |
| 22:03:20 | sean-k-mooney | that might be worth it | |
| 22:04:15 | sean-k-mooney | fungi: its too bad we cant simulate this | |
| 22:04:21 | fungi | sure, i expect that depends on the project. ultimately though i think there's a lot more throughput to be gained by finding and fixing the bugs that lead to nondeterministic test results than in optimizing for failure | |
| 22:04:53 | sean-k-mooney | well i hope we are trying to do both | |
| 22:06:00 | fungi | sure, but the resources consumed by build failures far outweigh the meager gains from shuffling them around in the available resource pool | |
| 22:07:43 | stephenfin | efried: Alrighty, functional, unit and pep8 tests passing so I'm going to push up this rebase of PCPU onto vPMEM. Can you spin through it and check out the conflicts when I do? | |
| 22:08:23 | mriedem | fungi: i apologize for rousing you into this channel and discussion | |
| 22:08:32 | mriedem | s/rousing/conjuring/ | |
| 22:09:15 | fungi | mriedem: no apologies needed. i'm just sorry if i derailed otherwise stimulating discussion in here ;) | |
| 22:09:42 | fungi | i do still recommend devstack changes on the feet though... so soothing | |
| 22:09:58 | efried | stephenfin: will do. | |
| 22:10:17 | efried | stephenfin: actually, hold on | |
| 22:10:22 | sean-k-mooney | fungi: the scheduling probalem for gate jobs has a lot of similar challanges to nova schduler problem for vms btu a lot of difference too | |
| 22:10:31 | stephenfin | holding | |
| 22:10:46 | efried | stephenfin: cpu-resources #1 just passed check and entered gate | |
| 22:10:48 | mriedem | fungi: before you showed up and professionaled it up we were talking about artom's beautiful brown eyes | |
| 22:10:56 | efried | stephenfin: but #2 is failing check | |
| 22:11:02 | stephenfin | efried: where are you seeing this? | |
| 22:11:04 | mriedem | sean-k-mooney: i already said we should use zuul as a nova scheduler driver in -infra months ago | |
| 22:11:08 | mriedem | dibs on that ideea | |
| 22:11:21 | efried | stephenfin: so if possible, just rebase #2+ onto vpmem | |
| 22:11:31 | sean-k-mooney | hehe its all yours | |
| 22:11:31 | efried | I... think that should be possible. | |
| 22:11:56 | sean-k-mooney | mriedem: add a ai or ml to it and you have your self a start up | |
| 22:12:06 | stephenfin | efried: I don't think I can straddle another branch like that | |
| 22:12:19 | stephenfin | I'd need to pull in vpmem between #1 and #2 | |
| 22:12:28 | stephenfin | which means pulling that out of the queue | |
| 22:12:30 | efried | yeah, boo | |
| 22:14:10 | sean-k-mooney | even when its a pain im still glad we have the ci that zuul/infra provides. can you imaging merging all this stuff by hand and testing it like the kernel does | |
| 22:15:16 | efried | alex_xu: Yes, please do, I don't think there's anything you need to do here. Thanks for all the work. | |
| 22:15:44 | alex_xu | efried: stephenfin sean-k-mooney thank you all :) | |
| 22:16:18 | sean-k-mooney | alex_xu: night o/ | |
| 22:16:22 | efried | stephenfin: I guess the choices are 1) wait for #1 to merge -- gate queue looks to be <2h -- then rebase the remainder on vpmem; or 2) rebase all right now and lose the +V on #1 | |
| 22:16:39 | stephenfin | I've just going to rebase | |
| 22:16:41 | stephenfin | it's one patch | |
| 22:16:55 | stephenfin | if I don't, we'll need to rebase vpmem | |
| 22:17:09 | stephenfin | to pick up the newly merged patch from master | |
| 22:17:28 | efried | not sure about that. But.. okay. | |
| 22:17:30 | sean-k-mooney | because of a conflict? | |
| 22:17:42 | efried | no, because 2+ relies on 1 | |
| 22:17:51 | stephenfin | ^ that | |
| 22:17:56 | sean-k-mooney | oh ok ya | |
| 22:18:10 | sean-k-mooney | thats our green check policy | |
| 22:18:29 | stephenfin | maybe the gate will rebase for me. idk | |
| 22:18:47 | sean-k-mooney | the gate will merge in some case but never rebase | |
| 22:18:48 | stephenfin | doesn't seem worth worrying about though. it's easy to hit recheck all weekend long | |
| 22:19:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793 | |
| 22:19:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693 | |
| 22:19:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add 'InstanceNUMATopology.cpu_pinning' property https://review.opendev.org/680106 | |
| 22:19:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Validate CPU config options against running instances https://review.opendev.org/680107 | |
| 22:19:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Use sane indent https://review.opendev.org/680229 | |
| 22:19:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field https://review.opendev.org/680108 | |
| 22:19:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800 | |
| 22:19:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571 | |
| 22:19:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Additional functional tests for pinned instances https://review.opendev.org/681750 | |
| 22:19:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Include both VCPU and PCPU in core quota count https://review.opendev.org/681374 | |
| 22:19:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801 | |
| 22:19:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fakelibvirt: Make 'Connection.getHostname' unique https://review.opendev.org/681060 | |
| 22:19:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Mock 'libvirt_utils.file_open' properly https://review.opendev.org/681061 | |
| 22:19:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895 | |
| 22:19:44 | stephenfin | oh thank God | |
| 22:19:56 | stephenfin | I was terrified I'd accidentally rebase vpmem :-D | |
| 22:20:39 | sean-k-mooney | ok so now in thery i can create a job that depens on pcpu+vpmem and numa LM right in my testing changes | |
| 22:21:10 | sean-k-mooney | since artom rebased LM there shoudl be no conflict anymore right | |
| 22:21:17 | stephenfin | correct | |
| 22:21:38 | sean-k-mooney | im going to check that locally. | |
| 22:22:09 | sean-k-mooney | also i really like git at times like this | |
| 22:23:39 | efried | stephenfin: that's weird, how did https://review.opendev.org/#/c/671793/ end up with a -2 from me on it? Usually that only happens if you wound up identical to an earlier PS that was -2 | |
| 22:24:10 | sean-k-mooney | ya i can merge https://review.opendev.org/674895 with https://review.opendev.org/#/c/640021 | |
| 22:24:12 | stephenfin | Looks like it was one of your procedural -2s | |
| 22:24:25 | stephenfin | I suspect git thinks the diff is the same | |
| 22:24:29 | stephenfin | as an earlier PS | |
| 22:25:06 | sean-k-mooney | ya if gerrit detect there is no change via a rebase it keps +/- 1/2 | |
| 22:25:28 | sean-k-mooney | that stops peole just rebasign to clear negitive reviews | |
| 22:25:41 | stephenfin | I wish Gerrit had some way to view just the diff between two versions side-by-side without all the additional context introduced in between | |
| 22:26:01 | stephenfin | As it is, I've to open different versions of the review in different tabs and toggle between them | |
| 22:26:07 | sean-k-mooney | thats a 4 way diff and i think the new ui can do it | |
| 22:26:13 | stephenfin | o rly? | |
| 22:26:29 | sean-k-mooney | apparently althogh i have not see it in partice | |
| 22:26:49 | sean-k-mooney | im sure we could still break it | |
| 22:27:55 | melwitt | git review -m <review num>,PSold-PSnew will do it, fwiw | |
| 22:27:59 | sean-k-mooney | you creat it by taking the origin patch angainst base and the updatdate patch against new base then diff the two diffs | |
| 22:28:49 | melwitt | https://docs.openstack.org/infra/git-review/usage.html | |
| 22:29:22 | sean-k-mooney | i dont know if that ignore change intoduce by rebasing | |
| 22:29:46 | stephenfin | it does not :( | |
| 22:30:04 | sean-k-mooney | but the process i discribe should do that | |
| 22:30:30 | melwitt | it did for me last time I tried it a few days ago | |
| 22:30:38 | stephenfin | at least if I do 'git review -m 671793,24-25' I see all the vpmem stuff introduced | |
| 22:30:43 | stephenfin | maybe I've an old version of git-review | |
| 22:31:10 | sean-k-mooney | melwitt: it will do it if you dont rebase between 4 and 10 | |
| 22:31:26 | melwitt | I mean I did a diff after a rebase between | |
| 22:31:55 | stephenfin | sean-k-mooney: yeah, 'git format-patch HEAD~N > (old|new); diff -r old/ new/' would do the trick | |
| 22:32:20 | stephenfin | melwitt: I imagine the difference could be that that rebase didn't introduce changes to the files you were touching | |