Sunday, 2019-08-18

*** saneax has joined #zuul02:29
*** mattw4 has quit IRC02:43
*** saneax has quit IRC04:12
*** bhavikdbavishi has joined #zuul04:40
*** bhavikdbavishi has quit IRC05:28
*** armstrongs has joined #zuul06:27
*** armstrongs has quit IRC06:37
*** ianychoi_ has joined #zuul07:06
*** sshnaidm|afk has quit IRC07:36
*** sshnaidm|afk has joined #zuul07:51
*** sshnaidm|afk has quit IRC08:07
*** sshnaidm|afk has joined #zuul08:08
*** sshnaidm|afk has quit IRC08:53
*** sshnaidm has joined #zuul08:55
*** bjackman_ has joined #zuul09:00
*** mgoddard has quit IRC09:50
*** mgoddard has joined #zuul09:51
*** sshnaidm has quit IRC10:32
*** sshnaidm has joined #zuul10:32
*** altlogbot_3 has quit IRC11:43
*** altlogbot_1 has joined #zuul11:45
*** noorul has joined #zuul11:51
noorulofosos: hi11:52
noorulofosos: hi12:08
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: DNM: Testing emit-role-header change  https://review.opendev.org/67709012:16
ofososhi12:17
ofososnoorul: so what's the state of your installation12:17
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: DNM: Testing emit-role-header change  https://review.opendev.org/67709012:18
noorulofosos: I made good progress12:23
noorulofosos: I am testing some use cases now12:23
noorulofosos: one of the use case that I am testing is. Approving PRs with conflicting changes.12:24
noorulofosos: But Zuul is not catching this :(12:24
ofososYou mean like in git conflicts?12:24
noorulYes12:24
ofososThey should not merge, because Bitbucket catches this12:24
noorulofosos: Zuul is supposed to merge them and test it12:25
ofososHow are you going to merge git conflicts?12:25
noorulofosos: Let us not take merge conflict case12:25
noorulofosos: Assume that there is PR1 and PR2 getting developed in parallel12:26
noorulofosos: But PR1 will not work with PR212:26
noorulofosos: On approving them parallely zuul is supposed to test them parallely12:26
noorulofosos: PR1 independently and PR1 + PR2 merged together12:27
noorulofosos: I am not seeing that happening12:27
ofososThat might be because there's no dependency handling.12:28
noorulofosos: This is same repository12:28
noorulofosos: I don't think for same repository we need dependency handling12:28
ofososAgain: there's no dependency handling, not even with PRs in the same repo.12:29
noorulOops!12:29
ofososI'm not sure if zuul should test pr1 + pr2 together, I've never seen that not even on gerrit12:29
noorulhttps://zuul-ci.org/docs/zuul/user/gating.html12:30
ofososI've only ever seen it test my change trains (with dependency handling): test change1, test change1+2, test change 1+2+3,... I've not seen it do that12:30
ofososDo you have a dependent pipeline configured?12:31
noorulI think that is what is missing12:32
noorulI have to try that12:32
noorulOk, I made gate pipeline dependent pipeline12:33
ofososThat behaviour should not depend on the Bitbucket driver12:33
noorulLet us see now12:33
noorulYes you are correct12:33
noorulLet me test it quickly12:33
noorulAnother thing I noticed is that sometimes when I resolve conflict and push, the jobs are not queued even waiting for sometime12:36
noorulofosos: In my setup build history is not there12:42
noorulofosos: Is there any specific steps for that12:42
*** bhavikdbavishi has joined #zuul12:44
noorulIt is not working12:50
noorulMaybe someone else in the channel can answer12:50
ofososnoorul: you need to set the pipeline to report to it and the mariadb driver needs to be configured13:01
ofososIn theory, whenever you push you should get a build, but hard to say without looking at the output of the scheduler and the pipeline config13:02
ofososWith the parallel testing, probably someone from this channel can help you on monday.13:12
*** saneax has joined #zuul13:13
noorulofosos: Here it is https://etherpad.openstack.org/p/rWL36RmF6W13:14
ofososnoorul: one thing you have to make sure is, that if you want the check pipeline to run, with you current configuration, check will just run if the pr is not mergeable13:19
*** saneax has quit IRC13:22
noorulofosos: I did not get that point13:23
*** bhavikdbavishi has quit IRC13:23
ofososYour check pipeline has a requirement canMerge: false. It'll not run if the bitbucket merge checks indicate it is mergeable13:24
ofososYour check pipeline has a requirement canMerge: false. It'll not run if the bitbucket merge checks indicate it is mergeable13:24
ofososUnder repo config, go to merge checks, set a condition that there must be at least one approval and one successful build. If the check pipeline is successful, it'll create a successful build, as soon as it is approved it will be mergeable (canMerge=true). After that check will no longer run and only gate will trigger13:26
ofososLike I said on friday/thursday, canMerge is implemented in terms of Bitbucket merge checks13:27
noorulok got it13:31
noorulI already had approval enabled13:31
noorulEnabled minimum successful build and set to 113:31
noorulofosos: Do you think my configs are all ok?13:32
*** saneax has joined #zuul13:32
ofososnoorul: I would change the gate pipeline trigger comment from "recheck" to "regate"13:34
fungilooking at the etherpad, you should be getting change dependencies (including unmerged parents) tested together in the check pipeline, and you should be getting changes approved at roughly the same time tested together in the gate pipeline13:35
noorulfungi: It is not working. I have two changes in the same file at the same line approved together13:35
noorulfungi: I see in the zuul status, there is a vertical line drawn13:35
noorulfungi: But I expect one to fail with merge conflict13:36
*** bjackman_ has quit IRC13:36
fungigot it. you should be able to tell from the inventory of a build for the second one whether it included the first in the repository it pushed to the job nodes13:36
fungiare they for the same branch?13:37
noorulfungi: no13:37
fungioh, if they're for different branches then how do they "merge conflict"?13:37
noorulfungi: I assume that this is how it works13:38
noorulfungi: checkout master13:38
noorulfungi: merge PR1 branch13:38
noorulfungi: then on top of that merge PR2 branch13:38
noorulfungi: Is my assumption wrong?13:38
fungizuul tests by merging pull requests to their target branches. it's possible i don't understand how bitbucket works but in gerrit a change is targeted to a specific branch and that's what zuul tries merging to13:39
fungipresumably the pull request indicates somewhere/somehow what branch it should be merged to, right?13:40
*** saneax has quit IRC13:40
noorulYes, the master branch13:40
ofososfungi: you create a seperate branch in the same repo and open a pr against master/develop/whatever13:40
fungiahh, so not like github then where you submit pull requests from branches of other repositories13:41
noorulfungi: In github also there will be same scenario13:42
fungiahh, okay. i use github only barely more often than bitbucket13:42
ofososfungi: no, that's not usually the workflow. You can do that with private repos, but private repos are not supported by the driver right now. That said, we don't use private spaces, because our installation does not have the correct permissions for this to work.13:42
noorulfungi: Let me explain once again13:43
fungiso anyway, the pr somehow indicates what branch it should be merged to, which is what i was initially asking: do both pull requests target the same branch (e.g., master)?13:43
noorulfungi: Yes, both the PRs target to master branch13:43
fungiif they target different branches then zuul won't know it should try combining them13:43
fungiif they target the same branch, then the scheduler should over gearman for a merger to try to combine them so that the executor can push the result to the job node13:44
noorulWhere can I see the log?13:44
fungiif the merger is unable to resolve the merge conflicts between them, then the scheduler should report with a failure comment for that buildset13:45
noorulfungi: That is not happening13:45
fungiare you collecting build logs from the job nodes yet?13:46
fungiif so, you can look in the inventory for one of the builds on the second pr to be enqueued and confirm whether it includes the first change13:46
noorulfungi: the builds URL is returning 404 for me13:46
noorulfungi: That is another problem I am facing13:47
noorulweb_1        | 2019-08-18 13:47:34,999 INFO cherrypy.access.140354416395656: 10.240.132.90 - - [18/Aug/2019:13:47:34] "GET /api/tenant/demo/builds HTTP/1.1" 404 733 "http://10.29.12.160:9000/t/demo/builds" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0"13:47
fungiokay, in that case you can probably work it out from the service logs (the scheduler will log which merger performed the requested merge of those commits, and the log for that merger may contain additional output from the merge process)13:47
noorulfungi: Do you know how to configure to make build history work?13:50
noorulhttp://paste.openstack.org/show/759237/13:51
noorulBut the build continued and marked a successful13:52
fungifor the builds page issue, looks like the api is listening but returning a 404... possible the zuul-web service is logging why those requests fail13:52
noorulfungi: Nothing much in the zuul-web service log13:54
fungibut on that paste, yes it looks like maybe the bitbucket connection driver is eating merge failures? i will admit i've not had time to dig into the proposed source13:54
fungicertainly that BitbucketConnectionError exception looks unexpected13:55
fungiand apologies, i have to step away from the keyboard again for probably ~30 minutes13:56
fungioh, though that's attempt 1/4 so maybe it got retried?13:57
fungianyway, back shortly13:57
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709314:10
ofososfungi: how noorul: I think I know what's wrong. I've pushed a change, let's see how the tests go and then try it out.14:10
noorulofosos: Normally how do you build the containers?14:12
noorulofosos: When I do docker build -f .14:12
noorulofosos: It is not tagging the containers14:12
ofososnoorul: fungi: that merge failure is kind of expected. Bitbucket can't merge the pr and returns an exception. Should this be handled differently?14:12
noorulofosos: What is the change for?14:13
noorulofosos: Fixing the merge issue?14:13
ofososNo, I think the PRs branch variable should be set to the target branch, we currently set it to the source branch. Can anybody here confirm, that that should be the case.14:14
AJaegerofosos: please update the commit message to explain more on what this fixes and why it's done. That title alone is too little for reviewing14:14
ofososWhat merge issue? What should we do instead of failing, when those changes cannot be merged on top of each other?14:14
noorulofosos: I think build should not proceed with a merge issue14:15
ofososAJaege, I will.14:15
noorulofosos: Regarding container build, what is your workflow?14:15
noorulAJaeger: Do you have any idea how to configure build history?14:16
ofososI don't have the exact docker command at hand. I usually build the containers tag them for ECR and upload to ecr. I've an alias on my work laptop to do this.14:19
ofososnoorul, I think the entire problem here is that zuul cannot see which branch these changes are for, so does not merge the testing. I'm trying to change that now.14:22
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709314:24
ofososAJaeger: done14:25
AJaegernoorul: sorry, no idea14:29
ofososIs zuul.openstack slow today? It seems to take a long time to enqueue my tests.14:30
noorulofosos: Can you help with build history? Do you have anything extra other than what is in etherpad in your configs?14:36
ofososnoorul: yes you need to configure the mysql reporter for this to work, this needs to be part of your pipeline14:38
*** noorul has quit IRC14:42
*** noorul has joined #zuul14:43
noorulofosos: Can you share the config?14:43
ofososnoorul: I don't have access to that right now. But it should be a simple `mysql:` line in the right place in the pipeline, see https://zuul-ci.org/docs/zuul/admin/drivers/sql.html14:44
ofososSpecifically reporter configuration at the end14:45
fungier, 30 minutes is turning into a lot more, but will return soonish i hope14:48
noorulI wish there is a complete example L(14:49
noorul:(14:50
noorulofosos: How do you build containers from your local changes?14:52
ofososnoorul: that example is complete, you just add the name of the mysql connection to the `success:` or `failure:` lists of the pipeline, what else do you need?15:07
AJaegerofosos: http://zuul.opendev.org/t/zuul/status shows 677093 enqueued...15:10
ofososAJaeger, thanks for the quick response, I was looking at the wrong tenant :/15:11
noorulofosos: Yeah, that worked15:15
noorulofosos: The Change link seems to be incorrect15:16
noorulhttp://10.29.12.160:7990/projects/demo/test/repos/test/browse15:16
noorulShouldn't that be pointing to the PR15:17
noorulhttp://10.29.12.160:7990/projects/DEMO/repos/test/pull-requests/6/overview15:17
noorulofosos: Can you re-base your patch? I think lot of UI enhancements went in recently. I am not able to see the same UI as zuul.opendev.org15:23
noorulhttps://imgur.com/P5YuOdA15:23
noorulThat is opendev one15:23
noorulThis is mine https://imgur.com/jbBlJKV15:24
*** ianychoi_ has quit IRC15:26
ofososLet me have a look at the change link15:32
ofososnoorul: can you post an example change link?15:32
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709315:34
noorulofosos: What do you mean?15:35
noorulThe non working example ?15:35
ofososLet's wait for the branch change to test. I made a note w.r.t. the pull url. I'll check that on monday15:36
noorulofosos: Is this re-based to master?15:38
ofososnoorul: no15:39
noorulofosos: Can you re-base?15:42
AJaegernoorul: we rebase change to HEAD everytime a we enqueue a change - so no need to rebase15:47
noorulAJaeger: How do I get the containers with these changes?15:49
AJaegersorry, I'm not a Zuul developer, just use it - and can't help with that. But if Zuul builds a container, it should be current15:50
noorulofosos: How do you get containers with your changes?15:51
ofososnoorul: I do `docker build...` in my local checkout15:52
*** pots has joined #zuul15:52
noorulofosos: How do you tag them?15:52
ofososnoorul: I do `docker tag...`15:53
noorulofosos: How do you identify which image id is for which service?15:53
ofososnoorul: I don't have that info at hand, but you can look it up in the docker docs.15:54
noorulofosos: I am now doing it using docker image history and finding out entry point and then tagging15:58
noorulofosos: which is cumbersome15:58
noorulofosos: I thought you had a better way of doing it15:58
AJaegerofosos: Ah, if you build those locally, then no automatic rebasing happens. This is only done by Zuul when testing it15:59
fungiokay, back now, sorry, catching up16:29
fungiofosos: yes, i think you've got it, the zuul branch should be whatever branch the request is targeting merge to, not whatever its source branch name was16:30
funginote that there may be jobs in the check pipeline for zuul which build container images, and if so those will be created by merging the series of changes into the current state of the master branch, in which case we likely archive the resulting images and you could test with those... just a sec and i'll check16:33
fungi677093 failed its unit tests by the way, though i haven't looked at why16:35
fungiyeah, the "artifacts" section of https://zuul.opendev.org/t/zuul/build/b632628c74734d70ac2806b07be9c4cb has some docker:// urls which presumably work16:36
fungithose should be the result of merging the proposed change(s) into master16:37
*** noorul has quit IRC16:52
*** noorul has joined #zuul16:52
noorulfungi: hi16:52
fungihi there16:53
noorulfungi: do you have any idea how to setup ara?16:53
ofososfungi: I think some of the assumptions I had previously are hardcoded into the testing code. I removed some and also cleaned up some code.16:53
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709316:53
noorulI have the role applied but it fails with no ara installation found16:55
funginoorul: i think it depends on how you're archiving your build logs (we used to run it as a wsgi app, but now we serve it from a generic object storage service instead, so the way you use the role may vary)16:55
fungioh, and yeah if you're running ara to generate content as part of the job, ara needs to be installed (either by the job or pre-existing on the node)16:56
noorulon each node?16:56
fungii believe for opendev we pre-install ara into a virtualenv in our node images16:56
nooruloh I see16:57
noorulis it on all the nodes?16:58
noorulor executor alone?16:58
clarkbits on tye executor16:58
clarkbin the venvs there. ara should already be a dep for that16:58
fungioh, we do ara content generation on the executors? i was still in the process of pulling up the role source16:59
noorulI am using example docker compose16:59
clarkbfungi: yes becausethat is where ansible runs16:59
fungigot it16:59
fungiwe install ara on the nodes for jobs which do nested ansible i guess?16:59
fungior maybe that was still an outstanding to-do after the opendev switch to object storage17:00
noorulSo if I do pip install ara on executor, will I start seeing the logs published?17:01
*** noorul has quit IRC17:04
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709317:54
*** saneax has joined #zuul18:22
*** dustinc has joined #zuul18:58
*** jamesmcarthur has joined #zuul19:24
*** jamesmcarthur has quit IRC19:41
*** jamesmcarthur has joined #zuul19:41
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709319:45
openstackgerritMark Meyer proposed zuul/zuul master: Change branch variable in PR  https://review.opendev.org/67709320:08
*** jamesmcarthur has quit IRC20:39
*** jamesmcarthur has joined #zuul20:39
*** jamesmcarthur has quit IRC21:27
*** jamesmcarthur has joined #zuul21:28
*** jamesmcarthur has quit IRC21:33
*** jamesmcarthur has joined #zuul21:48
*** jamesmcarthur has quit IRC21:57
*** jamesmcarthur has joined #zuul22:25
*** jamesmcarthur has quit IRC22:33
*** threestrands has joined #zuul22:39
*** jamesmcarthur has joined #zuul23:39
*** jamesmcarthur has quit IRC23:42
*** jamesmcarthur has joined #zuul23:42
*** jamesmcarthur has quit IRC23:51

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!