Open Stack

On Tue, 2019-02-26 at 11:35 -0500, Clark Boylan wrote:
> On Tue, Feb 26, 2019, at 3:04 AM, Sean Mooney wrote:
> > On Mon, 2019-02-25 at 19:42 -0500, Clark Boylan wrote:
> > > On Mon, Feb 25, 2019, at 12:51 PM, Ben Nemec wrote:
> > > > 
> > > 
> > > snip
> > > 
> > > > That said, I wouldn't push too hard in either direction until someone 
> > > > crunched the numbers and figured out how much time it would have saved 
> > > > to not run long tests on patch sets with failing unit tests. I feel like 
> > > > it's probably possible to figure that out, and if so then we should do 
> > > > it before making any big decisions on this.
> > 
> > clark this sound like a interesting topic to dig into in person at the 
> > ptg/fourm.
> > do you think we could do two things in parallel.
> > 1 find a slot maybe in the infra track to discuss this.
> > 2 can we create a new "fast-check" pipeline in zuul so we can do some 
> > experiment
> > 
> > if we have a second pipeline with almost identical trrigers we can 
> > propose in tree job
> > changes and not merge them and experiment with how this might work.
> > i can submit a patch to do that to the project-config repo but wanted 
> > to check on the ml first.
> > 
> > again to be clear my suggestion for an experiment it to modify the gate 
> > jobs to require approval
> > from zuul in both the check and fast check pipeline and kick off job in 
> > both pipeline in parallel
> > so inially the check pipeline jobs would not be condtional on the 
> > fast-check pipeline jobs.
> 
> Currently zuul depends on the Gerrit vote data to determine if check has been satisfied for gating requirements.
> Zuul's verification voting options are currently [-2,-1,0,1,2] with +/-1 for check and +/-2 for gate. Where this gets
> complicated is how do you resolve different values from different check pipelines, and how do you keep them from
> racing on updates. This type of setup likely requires a new type of pipeline in zuul that can coordinate with another
> pipeline to ensure accurate vote posting.
oh right because there would only be one zuul user for both piplines so they would conflict.
i had not thought about that aspect.
> 
> Another approach may be to update zuul's reporting capabilities to report intermediate results without votes. That
> said, is there something that the dashboard is failing to do that this would address? At any time you should be able
> to check the zuul dashboard for an up to date status of your in progress jobs.
for me know but i find that many people dont know about zuul.openstack.org and that you can view the jobs and there logs
(once a job finishes) before zuul comments back.

perhaps posting a comment when zuul starts contain a line ot zull.o.o would help the discoverability aspect.


> 
> > 
> > the intent is to run exactly the same amount of test we do today but 
> > just to have zuul comment back in two batchs
> > one form each pipeline.
> > 
> > as a step two i would also be interested with merging all of the tox 
> > env jobs into one.
> > i think that could be done by creating a new job that inherits form the 
> > base tox job and just invoke the run play book
> > of all the tox-<env> jobs from a singel playbook.
> > 
> > i can do experiment 2 without entirly form the in repo zuul.yaml file
> > 
> > i think it would be interesting to do a test with "do not merge" 
> > patches to nova or placement and
> > see how that works
> 
>