Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
22:01:18 fungi it might be that fast-fail would be more appropriate in a dependent pipeline if its changes are filtered through an independent pipeline first like happens with the openstack tenant
22:01:30 sean-k-mooney efried: ya if a voting job fails it would be cool if it did nto start any other job in the job set but continue runniinng the ones that are running
22:01:36 openstackgerrit Eric Fried proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata https://review.opendev.org/671074
22:01:37 openstackgerrit Eric Fried proposed openstack/nova master: Docs for isolated aggregates request filter https://review.opendev.org/667952
22:01:37 openstackgerrit Eric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates https://review.opendev.org/671075
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 efried I... think that should be possible.
22:11:31 sean-k-mooney hehe its all yours
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: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693
22:19:36 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793
22:19:37 openstackgerrit Stephen Finucane proposed openstack/nova master: Validate CPU config options against running instances https://review.opendev.org/680107
22:19:37 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'InstanceNUMATopology.cpu_pinning' property https://review.opendev.org/680106
22:19:38 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field https://review.opendev.org/680108
22:19:38 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Use sane indent https://review.opendev.org/680229
22:19:39 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571
22:19:39 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800
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:40 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Additional functional tests for pinned instances https://review.opendev.org/681750
22:19:41 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Make 'Connection.getHostname' unique https://review.opendev.org/681060
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:42 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895
22:19:42 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Mock 'libvirt_utils.file_open' properly https://review.opendev.org/681061
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

Earlier   Later