Wednesday, 2020-04-01

mnaserclarkb: yeah, this landed on limestone... so i'm trying to recreate the playbook locally00:00
*** shanemcd has joined #zuul00:04
*** dangtrinhnt has joined #zuul00:21
mnaserinteresting, it looks like it worked just fine here locally when i replicated it.  i'm re-running with verbose..00:29
*** rlandy has quit IRC00:36
*** dangtrinhnt has quit IRC00:37
*** dangtrinhnt has joined #zuul00:44
*** saneax has joined #zuul00:50
*** dangtrinhnt has quit IRC00:58
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645201:02
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645201:11
*** dangtrinhnt has joined #zuul01:17
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645201:23
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645201:34
*** swest has quit IRC01:35
*** dangtrinhnt has quit IRC01:37
*** dangtrinhnt_ has joined #zuul01:37
*** dangtrinhnt_ has quit IRC01:45
*** rfolco has quit IRC01:47
*** dangtrinhnt has joined #zuul01:47
*** swest has joined #zuul01:51
*** dangtrinhnt has quit IRC01:52
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645201:59
*** dangtrinhnt has joined #zuul02:01
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645202:10
*** ysandeep|away is now known as ysandeep|rover02:31
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645202:33
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645202:33
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645202:47
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645202:58
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645203:05
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645203:12
*** dangtrinhnt has quit IRC03:25
*** bolg has quit IRC03:34
*** bhavikdbavishi has joined #zuul03:42
*** bhavikdbavishi1 has joined #zuul03:45
*** bhavikdbavishi has quit IRC03:46
*** bhavikdbavishi1 is now known as bhavikdbavishi03:46
*** dangtrinhnt has joined #zuul04:00
*** evrardjp has quit IRC04:36
*** evrardjp has joined #zuul04:36
*** sgw has quit IRC05:07
*** sgw has joined #zuul05:24
AJaegermnaser, tobiash, please check the Zuul output in https://review.opendev.org/#/c/716334/ - lots of "Job openstack-tox-py37: unable to map line for file comments: ", can we avoid that?05:34
*** bolg has joined #zuul05:39
AJaegersame failure  on https://review.opendev.org/71637705:42
AJaegerand again on recheck of 71633405:49
*** bhavikdbavishi has quit IRC05:51
*** bhavikdbavishi has joined #zuul05:56
*** bhavikdbavishi has quit IRC06:16
*** bhavikdbavishi has joined #zuul06:37
tobiashZuul emits this warning if unchanged files are part of the returned line comments06:38
tobiashcorvus: shall we disable those warnings?06:39
tobiashAJaeger: also looks like it did emit some false positives06:40
AJaegertobiash: false positives? Not good. I suggest to disable those warnings - or show one at most06:45
tobiashThat seems to report line comments for stdin which seems like it matched a line that's not intended as line comment06:46
*** irclogbot_1 has quit IRC06:49
*** smyers has quit IRC06:51
*** tobiash has quit IRC06:51
*** jhesketh has quit IRC06:52
*** smyers has joined #zuul06:53
*** jhesketh has joined #zuul06:53
*** tobiash has joined #zuul06:53
*** fbo has quit IRC06:54
*** irclogbot_1 has joined #zuul06:55
*** fbo has joined #zuul07:00
*** jcapitao has joined #zuul07:02
*** ysandeep|rover is now known as ysandeep|brb07:03
*** avass is now known as Guest447107:11
*** dangtrinhnt has quit IRC07:11
*** avass has joined #zuul07:11
*** dangtrinhnt_ has joined #zuul07:12
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929207:22
*** bhavikdbavishi has quit IRC07:25
*** tosky has joined #zuul07:32
*** ofosos has joined #zuul07:37
*** ysandeep|brb is now known as ysandeep07:52
*** jpena|off is now known as jpena07:56
*** ysandeep is now known as ysandeep|rover07:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929208:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929208:19
*** bhavikdbavishi has joined #zuul08:22
bolgzuul-maint: there are several changes adapting tests to prepare them for multi-scheduler. Most of them are reviewed with 2* +2, missing due to recent changes: https://review.opendev.org/c/708812/13, https://review.opendev.org/c/709542/9, https://review.opendev.org/c/709735/8, https://review.opendev.org/c/712958/7  they do not introduce any braking changes and touch only the tests. Could someone please have a look?08:40
*** dangtrinhnt has joined #zuul08:44
*** dangtrinhnt_ has quit IRC08:48
*** kmalloc has quit IRC08:52
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds variable to toggle whether to revoke sudo  https://review.opendev.org/70624809:05
openstackgerritSorin Sbarnea proposed zuul/zuul master: WIP: Enable ANSI rendering on stdout/stderr  https://review.opendev.org/71625109:12
*** dangtrinhnt has quit IRC09:16
*** dangtrinhnt_ has joined #zuul09:17
*** dangtrinhnt_ has quit IRC10:26
*** jcapitao is now known as jcapitao_lunch10:37
*** ysandeep|rover is now known as ysandeep|afk10:56
*** harrymichal has quit IRC11:01
*** harrymichal has joined #zuul11:02
zbrI still see CORS header 'Access-Control-Allow-Origin' on job-output.json.gz. do we have a CR to address it?11:09
*** harrymichal has quit IRC11:21
*** harrymichal has joined #zuul11:22
*** ysandeep|afk is now known as ysandeep|rover11:22
*** dangtrinhnt has joined #zuul11:30
*** bhavikdbavishi has quit IRC11:36
AJaegertobiash, mnaser, another problem, please check https://zuul.opendev.org/t/openstack/build/f3f1712820c54140b5badf9c64ee6f3711:42
*** jpena is now known as jpena|lunch11:42
AJaegerthis passed py27 and failed in the parser for pep811:42
tobiashAJaeger: another revert?11:43
AJaegertobiash: if we can't fix it - yes :(11:44
*** cdearborn has joined #zuul11:44
AJaegerlet's first see whether anybody has a fix for it11:45
tobiashDepends on the urgency, I'm sure we can fix it11:45
tobiashBut right now I don't have time to work on it11:45
cdearbornFYI, the py27 gate job is broken for python-dracclient for both stable/queens and stable/stein11:46
cdearbornsee: https://review.opendev.org/#/c/716100/ and https://review.opendev.org/#/c/716101/11:46
cdearbornerror is: UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc0' in position 17520: surrogates not allowed11:47
cdearbornany ideas?11:47
AJaegercdearborn: we know what it is - a job change. Question is how to fix11:48
AJaegercdearborn: please give us some time to investigate - if we cannot fix it, we'll revert the change11:48
tobiashAJaeger: I think that unicode failure is easy to fix11:49
tobiashjust a sec11:49
cdearbornthx!11:50
arxcruzHi guys, i'm trying to add my role into one job in openstack, and i'm getting this error:11:53
arxcruzERROR Ansible plugin dir /var/lib/zuul/builds/fb47578b4bec4df09f82d3e417e5e4b6/ansible/pre_playbook_1/role_1/ansible-role-collect-logs/filter_plugins found adjacent to playbook /var/lib/zuul/builds/fb47578b4bec4df09f82d3e417e5e4b6/ansible/pre_playbook_1/role_1/ansible-role-collect-logs in non-trusted repo11:53
arxcruzansible-role-collect-logs is a trusted repo11:53
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: WIP: Try to fix unicode issue when parsing tox  https://review.opendev.org/71656011:53
tobiashcdearborn: can you test that with a depends-on? ^11:53
arxcruzthe review is https://review.opendev.org/#/c/702676/11:54
cdearborn@tobiash: sure11:54
tobiasharxcruz: inline filter plugins are not allowed for untrusted playbooks due to security reasons in zuul11:55
arxcruztobiash: i might be wrong, but ansible-role-collect-logs was supposed to be a trusted one11:55
*** dangtrinhnt has quit IRC11:55
arxcruztobiash: it's under openstack umbrella11:55
AJaegertobiash: a trusted jobs are defined in project-config11:56
AJaegerarxcruz: ^11:56
*** dangtrinhnt_ has joined #zuul11:56
AJaegerarxcruz: so, for Zuul it's not trusted11:56
arxcruzAJaeger: is it possible to add it to project-config ?11:56
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Ignore errors when parsing tox output  https://review.opendev.org/71656111:59
AJaegerarxcruz: I don't understand what you're doing here at all with your debugging. And I can't help you further myself. you might need to wait for later and discuss with others.11:59
tobiashAJaeger, cdearborn: and this should permanently ignore errors in that task ^11:59
AJaegertobiash: Thanks!11:59
arxcruzAJaeger: I'm trying to replace openstack-ansible log script with the ansible-role-collect-logs12:00
arxcruzAJaeger: but thanks, your information were valuable I'll check on my side now :)12:00
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929212:02
cdearborntobiash: got the same error after adding 'depends-on': https://review.opendev.org/#/c/716100/ - is it not working or did i make a mistake?12:08
tobiashcdearborn: that was a shot in the dark, could you try a depends-on to https://review.opendev.org/716561 ?12:09
tobiashthat should just ignore that error12:09
cdearborntobiash, sure!12:09
tobiashthe fix might be a little bit more difficult as I though as it happens inside of ansible12:09
*** rlandy has joined #zuul12:11
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929212:11
openstackgerritTobias Henkel proposed zuul/nodepool master: Add debug info on json parse error of image upload  https://review.opendev.org/71656612:15
*** dmellado has quit IRC12:15
*** Goneri has joined #zuul12:16
*** jcapitao_lunch is now known as jcapitao12:16
cdearborntobiash: nope, that didn't do it.  Now there's a 2nd error about a possible syntax error: https://review.opendev.org/#/c/716100/12:23
*** rfolco has joined #zuul12:23
*** dmellado has joined #zuul12:23
AJaegertobiash: https://zuul.opendev.org/t/openstack/build/d3eabd8f9cc94db6b80c9a3c2eb2a060 is the error12:23
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Ignore errors when parsing tox output  https://review.opendev.org/71656112:28
tobiashAJaeger: updated ^12:28
AJaegertobiash: left a question for you12:31
*** rpittau has joined #zuul12:32
mnasermorning12:33
mnaserokay, looks like i'm here just in time..12:33
AJaegermorning, mnaser ! Yeah, a bit of fun in scrollback ;912:33
mnaserk12:35
* mnaser looks12:35
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Ignore errors when parsing tox output  https://review.opendev.org/71656112:35
tobiashAJaeger: ^12:35
mnaserok i think i have a solution12:37
mnaserdo we maybe wanna give it a try or lets merge this for now?12:37
tobiashmnaser: I think we should do both12:38
tobiashignore errors and fix the error :)12:38
tobiashwe'll still see the error anyway so ignoring them won't hinder us from fixing the underlying issue12:39
mnasertobiash: agreed12:40
mnasertobiash: also it's not as straight forward as it seems to be in the ansible layer12:40
tobiashmnaser: yes, I noticed that too ;)12:40
mnaserAJaeger, tobiash: +3 for now..12:42
tobiash\o/12:42
AJaegermnaser: want to dig into https://review.opendev.org/#/c/716334/ or https://review.opendev.org/716377 - we should get rid of these warnings12:44
AJaegerpython-dracclient is passing the py27 jbos with depends-on now!12:45
AJaegercdearborn, tobiash, mnaser , looks like we're green! ^12:45
tobiash:)12:46
*** jpena|lunch is now known as jpena12:46
mnasertobiash: i might have a really silly workaround12:46
mnasertobiash: this whole thing happens because ansible tries to log things into syslog it's actions and that big blob of string data probably makes it unhappy as it tries to encode it and log to syslog12:46
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Add support for RedHat platforms on install-podman  https://review.opendev.org/71657812:47
mnasertobiash: if we set that task to 'no_log' .. we avoid that... https://github.com/ansible/ansible/blob/stable-2.9/lib/ansible/module_utils/basic.py#L1945-L195712:47
tobiashthat is a really ugly workaround and makes it impossible to debug that script12:47
mnaserah, no_log doesn't log errors anymore too in the console?12:48
mnaserby errors i mean tracebacks12:48
tobiashno_log will cause nothing to log at all not even errors12:49
tobiashthat's intended to protect secrets normallyu12:49
mnasertobiash: wait, what if we marked the argument in the module as a secret, it looks like this fucntion loops over all the params and skips the no logged one?12:49
mnaserthat will keep it still running but it will not log the whole wall of text into syslog12:49
tobiashis that possible?12:50
mnaserthe code that i linked makes it seem like it's looping over values12:50
mnaseroh yes it is12:50
mnasersee this test https://github.com/ansible/ansible/blob/308723c3ca1122363e419070f1fa1d76ff5611a9/test/units/module_utils/common/parameters/test_list_no_log_values.py#L1812:50
tobiashcool, I don't think we'll want to log the stdout of the tox output again anyway12:51
mnaserhttps://github.com/ansible/ansible/blob/308723c3ca1122363e419070f1fa1d76ff5611a9/test/units/module_utils/basic/test__log_invocation.py also is specific to our failures12:51
mnaseryeah exactly12:51
mnaserokay let me try12:51
zbrolder improvement on ensure-tox: https://review.opendev.org/#/c/690057/12:53
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: tox_parse_output: add no_log to tox_output  https://review.opendev.org/71657912:54
mnasertobiash, AJaeger ^ something like this12:55
tobiashif that works that would be a damn simple fix :)12:55
openstackgerritMerged zuul/zuul-jobs master: Ignore errors when parsing tox output  https://review.opendev.org/71656112:55
mnasercdearborn: would it be cool to try your patch again with that briefly12:55
mnaserwith a "Depends-On:12:55
mnaserDepends-On: https://review.opendev.org/71657912:56
mnaser(it could even be another unrelated patch)12:56
zbrmnaser: i think i missed the issue with tox output, what happened? the idea of hiding output worries me from UX point of view.12:56
AJaegermnaser: we merged 716561 too fast, so you want to merge with 716561 reverted12:56
mnaserAJaeger: i think we would still catch the failure12:56
AJaegerzbr: check 716579, it's not tox_output, it's tox_outpu as input to a parser ;)12:56
mnaserzbr: we're not hiding tox output, we're hiding tox output from being registered as a param for the module that scans the output for inline comments12:56
mnaserAJaeger: going back to your point, i think the job will still pass, but we'll just have to review logs by hand after to make sure it didn't raise any exceptions12:57
zbrmnaser: huh, happy to hear that.12:57
AJaegermnaser: you can create your own change for dracclient on top of cdearborn's with depends-on13:01
*** hashar has joined #zuul13:05
cdearbornmnaser, sure thing - sorry had to step away for a bit13:05
*** bhavikdbavishi has joined #zuul13:09
mnasercdearborn: cool, no worries, ill wait for you13:14
mnaserAJaeger: juggling through a million things this morning :p13:14
AJaegermnaser: no worries13:17
zbri want to prose a change on how tox role runs: when it gets a (command separated) list of envirnments to split it and to run tox each time with a single environment13:18
openstackgerritMerged zuul/zuul-jobs master: tox_parse_output: add no_log to tox_output  https://review.opendev.org/71657913:18
zbrthis will improve UX because user may be able to see the error on exactly the failed environment instead of having the error "lost" from that default tail.13:19
zbrif this sounds ok, i can propose a PR for implementing it.13:19
cdearbornmnaser, AJaeger, tobiash: All green! https://review.opendev.org/#/c/716100/13:19
*** dangtrinhnt_ has quit IRC13:20
tobiashyes, that seems to have fixed it13:21
mnaseryay!13:21
mnaseri'll use that as a "learning experience" for the golangci-lint one im doing :p13:21
*** dangtrinhnt has joined #zuul13:21
cdearbornmnaser, AJaeger, tobiash: thank you all so much for all your help and for so quickly fixing this.  I really appreciate it!!!13:22
*** dangtrinhnt has quit IRC13:23
*** dangtrinhnt_ has joined #zuul13:23
*** dangtrinhnt_ has quit IRC13:24
AJaegercdearborn: sorry for breaking your change - and thanks for the help getting it fixed!13:26
cdearbornAjaeger: no problem - glad to help13:27
mordredmnaser: one more followup - we might want to strip ansi chars from the message in the pep813:52
*** smcginnis has joined #zuul13:52
mordredmnaser: see https://review.opendev.org/#/c/697636/10/cinder/tests/unit/volume/drivers/vmware/test_fcd.py@567 as an example :)13:52
* mordred goes to look13:52
AJaegeryeah, https://review.opendev.org/#/c/697636/10 has 432 comments ;(13:52
AJaegersmcginnis: ^13:52
AJaegermnaser, tobiash, clarkb, mordred : Did either of you volunteer to send an announcement about this change?13:53
AJaegermordred: but those are wrong errors, it should never have left those 432 at all!13:54
AJaegermordred: oh, they come from pylint...13:54
*** bhavikdbavishi has quit IRC13:55
AJaegertobiash, mnaser, what about prefixing the comments with the job,, so ssay "openstack-tox-pylint : E1120: No value for argument 'get_disk_type' in method call ([no-value-for-parameter)13:56
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Strip ansi codes from pep8 message  https://review.opendev.org/71659813:56
AJaegermordred: you speak about pep8 messages - but it could be pylint or sphinx as well ;)13:57
smcginnisIs there a reason we have this now? We have plenty of pylint errors. We don't want them pointed out on every patch.13:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929213:57
avass^^^ anyone want to take a look at that13:57
avassactually I should add a test for the environment variables, one sec13:58
mordredsmcginnis: this is mostly intended as an improvement for the pep8 job - I don't think we considered people running non-voting linters that they didn't care about ... let's see what we can do about that13:58
AJaegersmcginnis: https://review.opendev.org/#/c/715727/ is the change - and we really had pep8 only in mind13:59
AJaegermordred: tobiash wants to extend to sphinx as well, see https://review.opendev.org/#/c/716264/113:59
tobiashmordred: we could check the voting flag and skip if non-voting?14:00
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Strip ansi codes from pep8 message  https://review.opendev.org/71659814:01
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add flag for toggling inline comments for linters  https://review.opendev.org/71659914:01
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:01
mordredAJaeger: cool14:01
avassthat should do it14:01
mordredsmcginnis: I mean - also - maybe stop running that pylint job since it's clearly a waste of time and energy? if there are 432 errors and the job is nonvoting, I'm pretty sure nobody ever looks at it and it's just burning vms14:02
mordredsmcginnis: (we'll clearly fix this - but it's a good indication to me additionally that that job is a waste of time)14:02
mordredtobiash: there's a patch adding a flag to toggle if off14:02
smcginnismordred: We want to find new ones that are introduced when files are touched, but pylint has so many false positives that it's useless to gate on it.14:02
smcginnisSo it's a balance of trying to get the benefit out of it, versus limiting noise.14:03
smcginnisAnd this just brought a whole lotta noise.14:03
mordredsmcginnis: I've been arguing that pylint is useless for like 8 years now - but shrug14:03
mordredtotally - we'll fix that part - and sorry about that14:03
tobiashmordred: should we change that flag to opt-in rather than opt out?14:05
smcginnisIf we just need to set a flag in the cinder .zuul.yaml, I think that's a fair approach.14:05
mordredsmcginnis: remote:   https://review.opendev.org/716600 Turn off inline comments on pylint14:05
smcginnis++14:06
mordredtobiash: no - I mean, I think it's a good feature that should normally work for people - the normal case is to run jobs you care about and the info from them should be valualbe, so I think the "we run this, normally mostly ignore it, but it's sometimes valuable for reasons" is the exceptional case14:06
tobiash++14:07
mordredsmcginnis: my hunch is that it's noisy for most people running that job - so let's do it globally instead of just in cinder ... people can always opt-in on a pylint job if they want to in their repo - but I'm betting _most_ people runnig pylint are not gatig on it and are probably in a similar situation14:07
smcginnisYeah, that makes sense.14:08
smcginnisAnd I would assume locally setting that to true would override that? Then if a project does really care, they can flip it on for their repos.14:08
tristanCcould the inline comments be restricted to voting job that failed?14:10
mordredsmcginnis: yes, that's right14:10
AJaegermordred: and can we add a note on which job reports? So, you want to know whether it's sphinx, pep8, pylint or whatever reports...14:11
mordredAJaeger: yeah - I think that's a good idea14:11
mordredtristanC: I think we could - but let's wait on doing that for a bit and operate under that assumption that people are running jobs whose output they care about - and disable things when that isn't the case, rather than starting from an assumption that jobs are noise and signal is the exception14:12
mnaseri agree with mordred -- i think running linters that are non-voting is the exception to teh rule imho14:14
mnaseralso as an infra donor, it's a little bit of a bummer to see resources go to waste like that running a non-voting job that no one cares to fix14:14
AJaegermnaser: could you +2A https://review.opendev.org/#/c/716600/ , please?14:14
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add tox_envlist to the inline comment  https://review.opendev.org/71660114:16
mordredAJaeger, mnaser : ^^14:16
mordredwhat do you think about that?14:17
AJaegermordred: can we test that?14:18
mordredAJaeger: I think that's a great idea :)14:19
avasswhat python version are we using in zuul-jobs?14:19
mordredmnaser, corvus : https://review.opendev.org/#/c/715157/ this is a recent openstack-tox-pep8 failure - note that it says something about comments being left for invalid file14:19
mnaseri really signed myself up for a can of worms :)14:20
mordredI think it's ok - the change produced a change in arguments for a function which caused an error in a file that isn't in the change14:20
mnaserit'll be super awesome once this all is done14:20
mordredso - I think it's fine and is just life :)14:21
avassmordred: was going to comment that I very much prefer f-strings but had to check and they weren't introduced until python3.6 :(14:22
mnaserAJaeger: +3'd14:22
openstackgerritMerged zuul/zuul-jobs master: Add flag for toggling inline comments for linters  https://review.opendev.org/71659914:23
AJaegerthanks, mnaser14:23
mordredavass: yeah - tell me about it - I also very much prefer f-strings but 3.5 still abounds14:23
*** avass has quit IRC14:27
*** avass has joined #zuul14:27
mnasertoday on weird things14:27
mnaserthe work i was doing on golangci-lint was working great14:27
mordredAJaeger: remote:   https://review.opendev.org/716604 DNM Testing zuul job change14:28
mnaseruntil i moved the install-go to pre.yaml and it's the golangci-lint has been oom-ing since...14:28
mordredmnaser: o_O14:28
mnaseri mean, it could be a concidence14:28
mnaserhttps://review.opendev.org/#/c/716464/3 is what im testing it against14:28
mordredmnaser: it certainly don't seem like a thing that should oom because of that14:28
AJaegermordred: that change hasa broken .zuul.yaml ;(14:28
mordredhonestlky, it doesn't seem like a thing that should oom14:28
mordredAJaeger: fixed (too much delete)14:29
mnasermordred: i could swear the only change i did that made the ooms start happening was move to pre.yaml14:29
mnaseroh and btw, our install-go role is broken :)14:29
avassmnaser: it's broken?14:29
mnaserit returns meta: end_host if it detects go is installed already14:29
mnaserso if go is already installed and you run it twice14:29
avassah yeah, that was a mistake I made14:30
mnaserit happily exits the whole playbook14:30
mnaserno worries :14:30
mnaseri would say more a "bug" than "broken" :)14:30
avassI found it but haven't taken the time to fix it yet14:30
mnaseri will try to find time to figure out some clean alternative way of doing it14:30
avassgive me a second and I'll do it14:30
mordredmnaser: we shold makea. go-stow element and add support for consuming that to14:31
mordredtoo14:31
mordred:)14:31
mnasermordred: true, i think we're waiting for a dib release to hack on that, too many things at once14:31
mordredyah14:31
mordredmnaser: btw - dib was released with python-stow14:31
avassjust got off work anyway, and since I'm working from home I can do it while watching TV anyway :)14:31
mnaserooooo14:31
mnasermordred: step #2 is getting a nodepool image with a newer dib14:32
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645214:33
avassmnaser: how about this?14:34
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not end host if correct go version is installed  https://review.opendev.org/71660714:34
mordredmnaser: you should have a new nodepool image with new dib: https://review.opendev.org/#/c/716104/14:34
mordredavass: yes14:35
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add tox_envlist to the inline comment  https://review.opendev.org/71660114:38
mnaserok so golangci-lint latest seemes to have memory issues, v1.23.8 copes better14:38
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645214:42
corvusmordred, mnaser: was the ansi strip patch tested with a depends on? https://review.opendev.org/71659814:50
*** ysandeep|rover is now known as ysandeep|away14:50
mnasercorvus: i believe mordred has a change in the works that they're depended-on-ing14:50
mordredcorvus: https://review.opendev.org/#/c/716604/ should test it14:50
mnaserwhich also makes me feel we really should start building unit tests to this thing14:50
corvusmnaser: ++14:50
mnaseras it looks like it's picked up usage14:50
mordredcorvus: (the pylint output has the ansi)14:51
mnaserand it has a huge impact if we do something wrong14:51
corvusmordred: what about the envlist change, is that also tested?14:51
mnaseri'm a little deep in other things right now so i cant really write the tests :<14:51
AJaegerwe could also change the logic: Enable it for now only on the pep8 jobs.14:51
mordredcorvus: actually - both are tested with the same depends-on14:51
AJaeger(instead of disabling pylint)14:51
corvusk14:51
mnaseri dont like disabling it for a bunch of stuff14:54
*** hashar has quit IRC14:55
AJaegermnaser: where do we want it? On py37? On pylint? On py36? There're many tox based jobs...14:55
AJaegermnaser: I'm thinking of enabling it on a few until we're sure that it works fine and then enhance.. Maybe we don't need it14:56
mnaserAJaeger: well, we can just have our regex matchers that ignore it14:56
mnaseralso14:57
AJaegermordred: https://review.opendev.org/#/c/716604/ looks good - but since pylint is passing, we don't see the ansi code working14:57
mordredAJaeger, corvus : https://review.opendev.org/#/c/716604/2/cinder/context.py@2014:57
mordredyeah - I wasn't expecting pylint to pass since it failed SO BADLY on the other patch :)14:57
AJaegermordred: so, line 20 looks great!14:58
mordredthe ansi stripping at least didn't break the normal outpuot14:58
mordredoh - they only run pylint on files that changed in the change14:58
* mordred makes another version of that patch real quick14:59
AJaegermordred: will the changes fix also "Job openstack-tox-cover: unable to map line for file comments:15:00
AJaeger  stderr: 'fatal: There is no path stdin in the commit'15:00
AJaegerSee https://review.opendev.org/#/c/716573/15:00
corvusmordred, mnaser: would it be possible for you to collect samples of all the failed lines as you do this?15:01
corvusjust stick them in a file or a comment in the role for now15:01
corvusmordred, mnaser: but that will help us build up a library of content for the future unit test for this15:01
corvusif we lose it now, we'll never find out what sort of things broke it in the past, and if we refactor it, we'll discover this all again15:02
mordredAJaeger: I resubmitted the cinder DNM with a change that shoudl trigger a pylint error too15:02
AJaegermordred: and did you enable the pyling reporting?15:02
mordredAJaeger: yes15:02
AJaegergreat!15:03
AJaegerbbl15:04
mnasercorvus: i have actually been doing my failure collection inside the review itself that merged + been using teh same topic for a collection of DNM tests across projects so we can look there15:04
mnaserso at least we can go back and look at those reviews and see what warnings they have raised15:04
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add tox_envlist to the inline comment  https://review.opendev.org/71660115:05
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: WIP Add testing for inline tox comments  https://review.opendev.org/71662315:05
mordredmnaser: ^^ there's a change that grabbed soe of the cinder text15:05
corvusmnaser: i'm worried if we don't collect them in a file, we'll lose that.  as we've seen, it's really hard to go back and pick up the context from 6 month old changes with expired logs :/15:09
*** jcapitao is now known as jcapitao_afk15:09
corvusmordred: that's perfect, thanks!15:09
mnasercorvus: fair, is an etherpad cool?15:10
corvusmnaser: i think mordred's file in https://review.opendev.org/716623 is the place15:10
mordredmnaser: point me at some things and I can go grab it15:10
mordredmnaser: https://review.opendev.org/#/q/topic:pep8-inline-comments yeah?15:11
mnasermordred: https://review.opendev.org/#/q/topic:pep8-inline-comments15:11
mnaseryeah15:11
mnasermordred: https://review.opendev.org/#/c/610744/ was the biggest thing i was usnig to try mostly15:13
mnaserso you'll catch some warnings there15:13
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: WIP Add testing for inline tox comments  https://review.opendev.org/71662315:16
avasscorvus: regarding adding callbacks to the executor, how do we want to enable that? Whitelist any callbacks found in the callback directory or configure it in zuul.conf?15:16
corvusavass: oh that's a good question.  i was assuming zuul.conf, but that first idea is interesting.  though, are there a bunch of built-in callbacks we'd get if we did that?15:21
corvusmordred, tobiash: ^15:21
mordredWELL15:21
*** hashar has joined #zuul15:21
mordredI think we might want to configure this - because the move is towards callback plugins being provided in collections and they'll have namespaces (like ansible.posix.debug instead of debug) - so just scanning a dir isn't likely to be the most forward-compatible thing15:22
corvusoh good point15:23
*** zxiiro has joined #zuul15:23
avassah15:23
avassit's something we're going to want pretty soon so I'm looking into how we can do it at the moment15:26
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Add support for RedHat platforms on install-podman  https://review.opendev.org/71657815:26
tobiashcorvus: is that whitelisting or enabling?15:26
*** jcapitao_afk is now known as jcapitao15:29
corvustobiash: my memory may be fuzzy, but i thought they were the same thing?  that any whitelisted callback plugin gets called...15:30
avasstobiash, corvus: mostly whitelisting, configuration for the callbacks can be done with environment variables15:30
avassbut I guess having the configuration for the callbacks themselves in a file somewhere would be good too15:30
zbrhaha, bit funny to see zuul as reviewer, clearly easier to read. also it would work fine with ansible-lint too as it supports "parsable mode" (pep8 standard format)15:31
zbri wonder if this would not put so much load on gerrit that it would collapse, as I suspect a *big* number of comments from zuul.15:32
mordredcorvus, mnaser, clarkb, AJaeger : https://etherpad.openstack.org/p/N6V29rv4CA <-- how's that look for an email to openstack-discuss@15:33
avasstobiash, corvus: I think whitelisting is the only blocker for callbacks at the moment15:34
mordredavass: most can also be configured via ansible.cfg ... so maybe $something that causes $something to wind up in ansible.cfg would be easiest? (given how ansible is run via bubblewrap via zuul-executor so plumbing the env vars all the way through might get mind-bendy)15:34
avassmordred: right... I mixed up the zuul-executor with ansible itself15:36
mordredavass: close enough ;)15:36
avassso since I heard you guys like toml, it would be perfect to nest an [extra_ansible_cfg] under [executor] ;)15:39
mnasermordred: +1 -- ilike that, maybe point to teh reviews where we disabled the pylint output in case someone wants to enable it?15:39
mnaserbtw, while i am in timeout for losing all pipelines for the vexxhost tenant15:40
mnaserhow do we feel about renaming a role? something like the install-go one to ensure-go15:40
mnaseri think we can maybe use a symbolic link that will make it still continue to work on both sides?15:41
clarkbmordred: email seems ok. Idea I just had: could use a project level var to toggle inline comments on and off15:41
clarkbthen people can opt into it at a project level without changing jobs15:41
avassmnaser: I was thinking about that earlier15:41
*** bhavikdbavishi has joined #zuul15:42
avassI've been wondering if there's any difference between the install-* vs ensure-* roles15:42
avassor if everything should be ensure-* for consistency15:43
mnaseravass: i believe historically our consistency story has been ensure-*15:44
mnaserat least, that's the pattern i've mostly followed, ensure-$foo and $foo as roles15:44
avassmaybe copy the install-$foo roles to ensure-$foo and deprecate the install-$foo roles?15:46
mnaseri guess we could move it to ensure-*, keep a symlink and then announce the change in zuul-announce for 14 days15:46
avasshaha15:46
mordredmnaser, clarkb : updated - how's that?15:46
mnaserwell i think we just agreed to agree :)15:46
corvusmnaser, avass: ++ move for consistency15:46
mnasermordred: +2 from me :)15:47
clarkbmordred: lgtm, covers the toggle idea15:48
mnaserthis is a big leap but we should probably have some sort of 'zuul blog' so we can announce things like this and tweet them out to get excitement about them15:48
corvusmordred: looks good, bet we should probably do that in #opendev and send to service-discuss in the future?  :)15:48
mnaserb/c this is _pretty_ cool15:48
mordredcorvus: yeah - probably so :)15:48
mordredmnaser: and yeah15:48
mordredok. bombs away for now15:49
corvusmnaser, mordred: i think the cms work is near completion, but stalled?  we could do a simple static blog on the website15:50
mnasermordred: i saw you had soem work done at some point about gatsby-ing the website15:50
mordredyeah - that's on my TDL15:50
mordredI should really get around to finishing that15:50
corvusoh yeah, we can still do the gatsby part before the full gerrit integration, right?15:50
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663615:50
corvusso we'd still have a static website, just generated by gatsby?15:50
mnaserif there's not much work left... i can have someone who's working on gatsby-ing our website wrap it up15:50
corvusi'm using too much shorthand....15:51
mnaserand then i can use the roles in zuul-jobs to build and publish a site for our use too (as we're going to use gatsby to publish our site)15:51
corvusif i understand correctly, the long term plan is to convert the zuul website to a statically generated site using gatsby.  then, later, to integrate that into netlify-cms with the gerrit plugin that lets the cms web app propose changes to gerrit.15:52
corvusbut that first step is all we need right now in order to have a sensible static-generated blog15:52
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663615:52
avasshmm, I guess the documentation needs to be updated as well15:53
mordredcorvus: yes.15:53
mordredmnaser: what I've got is pretty stale - but I'll see if I can't do another pass at it this week - then it might be reasonable to have your human do a pass and fix whatever I did poorly15:54
AJaegermordred: just saw the cinder results - great!16:01
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663616:01
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663616:03
avass^ something like that16:03
avassI guess the tests need to be updated as well16:03
AJaegermordred: etherpad with mail draft LGTM16:03
corvusmordred: you cleverly made https://review.opendev.org/716601 self-testing :)16:04
AJaegerLol!16:05
openstackgerritMerged zuul/zuul-website master: Add redirect for /docs/zuul/user/  https://review.opendev.org/70919516:07
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663616:14
mordredcorvus: haha16:15
*** rpittau is now known as rpittau|afk16:15
mordredcorvus: https://review.opendev.org/#/c/716604/ <-- that shows ansi stripping and envlist prepending16:15
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add tox_envlist to the inline comment  https://review.opendev.org/71660116:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663616:17
avassI have a feeling this would have been easier to do in multiple changes16:17
clarkbavass: ya it might be easier to do a role at a time. Also you can have the odl role include the new role16:18
clarkb(to avoid needing to copy code between them16:19
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: WIP: Rename install- roles to ensure- for consistency  https://review.opendev.org/71663616:19
avassclarkb: ah I could do that instead16:22
AJaegercorvus: want to change your WIP to +A on https://review.opendev.org/#/c/716598/2 ?16:24
corvusAJaeger: yep, i went ahead and approved the followup too since it's just a whitespace change but has been shown to work16:25
AJaegerthanks!16:25
AJaegermordred, corvus, tobiash needs to rebase https://review.opendev.org/#/c/716263/1 now - what do you think of that one and the followup?16:26
corvusi think mnaser's suggestion makes sense, i think it might improve long-term maintainability16:30
tobiashI agree16:30
clarkbcmurphy pointed out in #openstack-infra that unittest jobs are generating output that ends up in zuul comments too. I think mordred is investigating but thought I'd mention it here16:31
clarkbhttps://review.opendev.org/#/c/716334/ is an example change16:31
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: WIP Add testing for inline tox comments  https://review.opendev.org/71662316:32
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Require a / in a file path  https://review.opendev.org/71665516:32
mordredclarkb: ^^ there's a fix I think for the cmurphy report - and also I added those lines to the patch where we're collecting output samples for future tests16:32
tobiashit's matching "stdin:27:1: K333  'import oslo_i18n.log' must be used instead of 'import oslo.i18n.log'."16:32
mordredyeah16:33
mordredso - the patch above just adds a / to the regex16:33
mordredbut maybe that's too simplistic and we shoudl do an os.path.exists instead?16:33
clarkbmordred: that will prevent doing top level .py files16:33
mordredclarkb: will theuy not show up at ./foo.py ?16:33
clarkbmordred: oh maybe16:33
clarkbsetup.py is probably the most important one, we could whitelist it if necessary16:34
tobiashmordred: is 716623 just collecting examples for a yet to create test case or did I miss the actual test?16:34
corvustobiash: it's the first thing, since everyone is too busy putting out fires to write the test right now :|16:35
tobiashos.path.exists can be difficult because we might not necessarily know the working dir16:35
tobiashah ok16:35
mordredI think I've got path.exists ...16:36
*** evrardjp has quit IRC16:36
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Use os.path.exists  https://review.opendev.org/71665716:36
*** bhavikdbavishi has quit IRC16:36
*** evrardjp has joined #zuul16:36
mordredtobiash: like that ^^?  (if that looks ok. I'll squash it on the regex update)16:37
tobiashmordred: if that works I think the regex update is not needed16:37
openstackgerritMerged zuul/zuul-jobs master: Strip ansi codes from pep8 message  https://review.opendev.org/71659816:37
* mnaser apologizes for opening the flood gates16:37
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Check that a file exists for inline comments  https://review.opendev.org/71665516:38
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: WIP Add testing for inline tox comments  https://review.opendev.org/71662316:38
mordredtobiash: let me send up a keystoneauth dn16:38
mordreddnm16:38
tobiashmordred: does chdir not work with a module?16:38
tobiashthat would simplify the path.exists check (and not break absolute paths)16:38
mordredremote:   https://review.opendev.org/716659 DNM testing inline comment fix16:39
mordredtobiash: oh - it should work16:39
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Check that a file exists for inline comments  https://review.opendev.org/71665516:40
mordredok. I rechecked the keystoneauth patch - hopefully that shows this working16:41
tobiashmordred: shall we use isfile instead of exists?16:42
tobiashthat would also filter out comments that point to a device file16:43
mordredtobiash: it's probably more correct16:43
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Check that a file exists for inline comments  https://review.opendev.org/71665516:43
tobiashlgtm16:44
openstackgerritMerged zuul/zuul-jobs master: Add tox_envlist to the inline comment  https://review.opendev.org/71660116:44
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666316:45
mnasercorvus: i have been thinking it would be pretty neat for us to add aarch64 tests to our 'all-platforms'16:46
mnaserit'd also make for a (kinda) trivial work (i think?) and also a really cool sort of announcement that zuul has native multiarch support and testing in it's roles16:47
mnaser(i'm working on some testing for the install-go -- soon to be called ensure-go and thought that would be a nice thing to add ...)16:48
fungiwe do still have limited capacity, delays, and frequent node failures for those16:49
fungii gather it's been improving, but not sure what our tolerance level is there16:50
clarkbthe big recent change was going to ipv6 only on the test nodes in the new arm64 cloud16:53
clarkbI think that gives us significanlty more capacity, but its still relatively small and those jobs do take longer16:53
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-kubernetes to ensure-kubernetes for consistency  https://review.opendev.org/71666716:53
avassuuh, how do you retrigger the gate? I'm confused16:54
avassregate? reverify?16:54
avassah nevermind it was just a bit slow16:55
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: go-jobs: improve testing  https://review.opendev.org/71666816:56
mnaserfungi, clarkb: i think we can use the approach ianw used for arm64 which is run them in a seperate pipeline16:57
clarkbmnaser: ya that is probably best to start. But we also need to be careful we don't consume all the arm resources testing zuul roles no one is using on arm yet16:58
clarkbI think my preference would be to identify roles that make sense and/or have known consumers on arm16:58
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Check that a file exists for inline comments  https://review.opendev.org/71665516:58
clarkbstart there and see how that works with current capacity16:58
mnaserclarkb: yeah i mean mostly i'm thinking it's for when we make a role change and we test across all of our platforms which only happens if we change a specific role16:59
mnaserclarkb: perhaps we can add another tag called "all-archs" and we are selective with what we test in arm, because obviously, ensure-tox is always going to work regardless of the architecture for example (...ideally)16:59
mnaserbut something like (install|ensure)-go might be a different story17:00
mordredyeah. actually, I feel like ensure-go might be the first thing in our bucket where arm might matter as a specific test target17:01
mnaserspeaking of which, it may be valuable for us to parse those tags somewhere else and document which roles/jobs are being tested against what platforms to have a nice presentable thing for users in our docs17:01
mnaserso there's no surprises when you try $foo on a combination of $arch/$os17:01
clarkbyup I think we can identify the roels that make the most sense and start with them17:01
clarkbthe docker stuff would likely be good too since kolla is one of the current consumers of arm resources17:02
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-kubernetes to ensure-kubernetes for consistency  https://review.opendev.org/71666717:06
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-openshift to ensure-openshift for consistency  https://review.opendev.org/71667517:06
AJaegermordred: https://review.opendev.org/716573 is another change with lots of comments " Job openstack-tox-py36: unable to map line for file comments: " if you need more ;)17:07
tobiashAJaeger: that looks like the same root cause and should be fixed by 71665517:09
AJaegergreat17:10
*** jpena is now known as jpena|off17:10
AJaegertobiash, mordred, do we have a test change up for that one? I can do one quickly...17:11
AJaegermordred: you're faster ;)17:11
AJaegerI'm approving https://review.opendev.org/#/c/716655/ now - the test in https://review.opendev.org/#/c/716659/2 looks fine17:13
mordredAJaeger: I agree - the test change has the lines in its log and appropriately did not try to leave them as comments17:17
tobiashmordred: we should now test a change where we expect line comments to make sure we don't filter all comments now ;)17:18
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666317:19
tobiashI'll push up a zuul change to test that17:19
mnasertobiash: i can un-abandon one of mine17:20
mnaseri have one with a few17:20
mnasertobiash: say like this one? https://review.opendev.org/#/c/610744/17:20
tobiashmnaser: yes, thanks17:21
mnasertobiash: restored :)17:22
mordredtobiash: good point :)17:23
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Test doc file comments  https://review.opendev.org/71668017:24
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Generalize parse tox output  https://review.opendev.org/71626317:29
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626417:29
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666317:31
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-kubernetes to ensure-kubernetes for consistency  https://review.opendev.org/71666717:31
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-openshift to ensure-openshift for consistency  https://review.opendev.org/71667517:31
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-podman to ensure-podman for consistency  https://review.opendev.org/71668217:31
mordredtobiash: (left comment, but I think it might be cleaner to rebase that on top of the stdin patch - since we're already passing in zuul_work_dir there now17:31
tobiashmordred: zuul_work_dir is not necessarily the same if we execute a tox in a subdir of a repo17:33
mordredhrm17:33
mordredtobiash: that's complicated then - because zuul_work_dir also might not be the same as ~/{{ project.src_dir }}17:34
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Do not end host if correct go version is installed  https://review.opendev.org/71660717:34
mordredtobiash: (I don't think we normally run linters in a different project than the triggering one of course ...)17:34
tobiashmordred: we do17:34
mordredah - nod17:35
tobiash(run in a subdir)17:35
mordredoh - yeah - subdir makes sense17:35
tobiashbut not necessarily pep817:35
mordredyeah17:35
tobiashbut I agree, running in a subdir will only work then if the output of the linter uses absolute paths17:35
tobiashbut I think that's a limitation we could accept17:36
mordredyah17:36
mordredso - yeah - maybe project.src_dir is probably the right thing to use now17:36
mordredthe main thing that might not work would be doing sphinx in the root of a project that is in required_projects but is not the project triggering the patch17:36
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929217:36
mordredsince you'd be looking for the wrong src_dir ... but maybe let's let someone complain about that use case before we try to figure out how to solve it17:37
tobiashmordred: yeah that's right17:37
mordredwe could expose the strip dir as a user-settable override so that people constructing such a job could just be explicit - but I don't think we need to do that today17:37
tobiashbut actually for my specific use case we're running doc builds (which need stripping because of sphinx) from the root17:38
*** bhavikdbavishi has joined #zuul17:38
openstackgerritMerged zuul/zuul-jobs master: Check that a file exists for inline comments  https://review.opendev.org/71665517:38
mordredgood - so I think it'll work for both of us with that logic17:38
tobiashso I think let's use the work dir first and find a generic subdir solution if needed later17:39
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645217:39
mordredtobiash: sounds good to me17:40
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-devstack to ensure-devstack for consistency  https://review.opendev.org/71668517:41
avassmnaser: are you renaming install-go or should I do it?17:41
mnaseravass: i am not renaming anything, i'll leave that for you :)17:41
avassalright :)17:42
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-javascript-packages to ensure-javascript-packages for consistency  https://review.opendev.org/71668717:44
mnaserzuul-maint: i have someone who is going to work on rebuilding the zuul-website using gatsby (which is really mostly using react to build sites) -- so it'll be quite similar to our dashboard -- with the same exact "theme" -- and then once they're done with that, we'll add a "blog" components so we can add markdown files to add new blog posts.  i think this will be really important to have a platform17:45
mnaserfor all teh cool new things we're doing (and helpful for the OSF to market as well)17:45
mnaserany strong feelings against that? :> it will continue to be all managed via git/code-review17:45
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Generalize parse tox output  https://review.opendev.org/71626317:46
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626417:46
clarkbmnaser: do we want to drastically change the theme of the existing site?17:47
clarkb(If I read it properly you're suggesting we use the dashboard theme on the main site)17:47
mnaserclarkb: i don't think they have any more time than just converting the current _exact_ site into a react based one mostly17:47
mnaserbut we can totally do something like that if we want to use patternfly eventually into it, but the goal is to really have a 1:1 mapping so we avoid having a whole discussion aroud "what looks good"17:48
mnasermordred: can we leave comments on a file that was not part of a change?  the error message i just got seems to imply "no"17:48
mnaseras i get a warning "Comments left for invalid file builders/pod_metrics_endpoint.go"17:48
mordredmnaser: nope, we can't17:48
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-go to ensure-go for consistency  https://review.opendev.org/71668917:48
mnasermordred: is that a zuul thing or? because, gerrit does support that17:49
mnasersee https://review.opendev.org/#/c/716464/3/builders/pod_metrics_endpoint.go which has no changes17:49
mnaser(this is a story of "i added linters into a repo that didnt have linters before")17:49
mordredmnaser: yesh - I thnk it's a zuul thing then17:50
clarkbmaybe I underestimate things but couldn't we continue to use the existing css then just have to generate html tags properly in gatsby?17:50
mordredclarkb: yeah - the gatsby conversion is just about converting how the website is made17:50
mnasermaybe we can revisit that? i can imagine being excited to add linters to your repo only to be greeted with no much inline comments17:50
mnaserclarkb: yeah pretty much that's what's going to end up happening17:50
mordredyeah17:50
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-javascript-packages to ensure-javascript-packages for consistency  https://review.opendev.org/71668717:50
mordredclarkb: we are _not_ talking about redesigning the website17:51
mordredjust reworking how it's built17:51
clarkbmnaser: ok thats not what I read above. I read that we'd be applying the zuul dashboard css to the website instead17:51
mordrednope17:51
mnaserahhhh, what i meant by similar to our dashboard was17:51
mordredlike dashboard in that it's react under the hood17:51
mnaser"we use react in our dashboard so in terms of maintainership, it's not going to be something exotic to us"17:51
clarkbquite similar to our dashboard -- with the same exact "theme" <- I think theme caused the confusion there17:52
clarkbyou mean theme of development not theme of rendering17:52
mordredah17:52
mordredI read that as "exact same theme as current website"17:52
mnaseryeah that was the intention, but yeah, we're all o the same page now :p17:52
clarkbfor the content side I think most of the current pages can probably be expressed as simple markdown type documents17:53
* mordred should move his gatsby website to opendev17:53
mordredyup17:53
clarkbthe front page is probably an exception to htat, but everything else can be markdown I think17:53
mordredas we want to do more complex things - gatsby has some really nice build-time features to do data-driven things via graphql17:53
mordredclarkb: but luckily - for thigns that need to do be straight html (or even just straight react) - it's trivial to do so17:54
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-nodejs to ensure-nodejs for consistency  https://review.opendev.org/71669217:54
* mordred has been very pleased with gatsby fwiw17:55
*** gmann is now known as gmann_lunch17:56
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-yarn to ensure-yarn for consistency  https://review.opendev.org/71669317:58
mnasermordred: i gues sthere was a reasoning behind this.. https://review.opendev.org/#/c/613161/17:58
mnaserthere's probably not really a trivial way of knowing if that file does exist or not17:59
mnasergiven the reporter code runs in the scheduler which does not have a copy of the codebase17:59
mordredyeah. it's an interesting thing - because on the one hand it protects against just trying to leave bogus comments18:00
mordredOTOH - for the use case you described, it can actually be useful to leave comments for valid files18:00
mordredeven if they aren't part of the change18:00
mnaseryeah..18:00
mnaserim not sure how we can detect that18:00
*** jcapitao has quit IRC18:00
mnaserinvalid file vs file-not-part-of-change18:01
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-pdk-dependencies to ensure-pdk-dependencies for consistency  https://review.opendev.org/71669518:01
mordredmnaser: yeah18:01
corvuser, we added that change because gerrit rejects comments not part of the changes?18:01
mnaserthats weird.  i can leave a -1 with a comment on a file that was not part of a change here: https://review.opendev.org/#/c/716464/318:02
mnasermaybe gerrit's behaviour changed? but i don't think we've updated since18:02
mnaseri guess it might reject it if it's comments for an actual file that doesn't exist18:02
corvusmnaser: how did you accomplish that?18:03
mordredsame question18:03
clarkbif you think about it from the perspective of a gerrit user whose pushed a change the last thing I/you/we want is a comment saying "someones code over here is broken"18:03
clarkbeven if gerrit allows it I'm not sure it is very helpful18:04
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-if-python to ensure-if-python for consistency  https://review.opendev.org/71669818:04
avassthat should be all of them, now they just need to pass their tests18:04
corvusclarkb: right, it's not actionable in this change.  it's probably most likely to happen in a change series, due to a previous change.18:04
mordredI disagree18:04
mnasercorvus: i manually edited the url when viewing a file, and then just left a comment18:05
mordredmnaser's use case was "I added a linter job and it broke a bunch of files"18:05
mordredyou'd need to fix those files in order to land the linter change18:05
mordredso I think it's totally actionable18:05
mordredand relevant to the change18:05
mnaserso i just went straight to https://review.opendev.org/#/c/716464/3/builders/pod_metrics_endpoint.go and left a comment18:05
clarkbmordred: but we don't have that context in gerrit18:05
clarkb(or zuul)18:05
mordred(same with "I chagned a compiler flag")18:05
mordredclarkb: what?18:05
clarkbmordred: all gerrit knows is you've updated the tox.ini (or equivalent)18:06
mnaseryou do because in the comment, you can still click and it will send you to the file18:06
clarkbit doesn't know that that effects all the .py files18:06
mordredclarkb: right - but the test job output _does_ know that18:06
mnaserthe -1 i left myself here still shows up: https://review.opendev.org/#/c/716464/3 -- pointing at the exact file/location18:06
mordredso if we can leave comments on files that aren't in the change, it's still potentially valuable to a reviewer18:06
*** reiterative has quit IRC18:06
clarkbmordred: yes, but if you are a drive by committer trying to land a simple bugfix the wrong thing is for the automated system to tell them they have to be am aintainer to land a bugfix18:06
mordredmnaser: I have reproduced your behavior18:06
fungican gatsby use restructuredtext too? just wondering if there's a way to avoid using different markup languages between our website and our docs18:06
corvusmordred: okay, but i think it's a bit of an edge case.  normally you would see this in a patch series, and you don't want to repeat the same errors on every patch in the series.  you want to see the errors for this change, and you want to go back to previous changes to see the errors there.  the same is true for thu zuul config errors, which is why we went to all the effort to make sure they only report on18:06
corvusthe relevant change.18:06
clarkbfungi: I think it is just markdown18:07
*** reiterative has joined #zuul18:07
mordredfungi: unfortunately no - restructuredtext hasn't gotten many non-python implementations18:07
fungii suppose then it's at least no worse than editing our docs in rst and our site in raw sgml18:07
mnaseryep...18:07
mordredif there was a javascript impl, gatsby would be able to support it18:08
fungiand if someone really cares, there are probably rst->md converters we could use to preprocess18:08
mnasercorvus: i don't know if i agree on this being an edge case, i guess if you never had linters and you just added them, it would be nice to see the output going in your files of what broke18:08
mnaseresp if we're going to say "hey it's not possible to easily lint you golang project, just add golangci-lint and see the inline comments!" .. oh wait, none of it shows up18:09
corvusmnaser: well, i feel pretty strongly that ci systems shouldn't be black boxes and people should be able to run linters locally.18:09
mordredsame with compiler flags, or dependency library updates which break a java build18:09
corvusmnaser: but moreover, surely adding a linter to a project for the first time is an edge case?  i mean, that really is not the normal course of business for a project, right?18:10
corvus(i'll grant it's maybe an edge case you think is worth handling)18:11
mnasercorvus: that's fair, i'll agree with you on that i think it's worth handling but it's not a common occurance :)18:11
mordredcorvus: I think adding a linter maybe be a bad specific example that also implies a potentially lower value - there are all sorts of dev activities which have impacts on code bases outside of the files touched. changing build settings in a makefile, updating a compiler setting, updating a dep in a strongly-typed/compiled language with a signature changing18:11
corvusand mordred is brainstorming some more common cases18:11
mnaserbtw, sidenote -- i have now golangci-lint reporting here: https://review.opendev.org/#/c/716464/4 yay!18:11
mordred"this patch updates to the latest hyper.rs library" - now there are 70 files that are using the wrong object signature for a method18:12
mordredof course, we don't support rustc yet :)18:12
corvusmordred, mnaser: so here's the information i have: when we had zuul reporting on all the errors, people really wanted it scoped down to just what the change is touching.  maybe this is different?18:12
mordredyeah - maybe?18:13
mordredbecause a zuul config change isn't going to have a knock-on effect (or shouldn't) like some of those other things18:13
mnaser++18:13
corvusmordred: sure it does.  otherwise it woudn't generate all those errors :)18:13
mordredalso - perhaps this a thing where there are valid arguments to be made in both direction18:13
mordredcorvus: :)18:13
clarkbmy real concern here is how do you differentiate that case from the case of I'm a drive by committer and the CI system wants me to maintain the software in order to land a simple bug fix18:13
clarkbbecause I think that is a really bad user experience18:14
clarkb(and I don't think we have enough context to differentiate)18:14
mordredclarkb: well - that's the case no mattrer what in this case18:14
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666318:14
mordredthose changes aren't going to alnd without those other fixes18:14
clarkbmordred: it depends if you do like the pylint thing18:14
mordredthe question is do we surface them in inline comments or only in the job console log18:14
clarkbwhich is apparently common enough18:14
mordredclarkb: let's ignore the nonvoting pylint case18:14
mordredwe fixed that18:14
clarkbmordred: sort of you didn't address the use case aiui18:14
mordredand assume that jobs aren't just completely bong18:14
clarkbyou just stopped doing it entirely18:14
mordredyes18:14
mordredbecause it'sa. bong job18:15
clarkbI don't think its bong18:15
mordredI do18:15
clarkbstatic checking on only the files that change is a very common thing18:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-kubernetes to ensure-kubernetes for consistency  https://review.opendev.org/71666718:15
mordredit is a job producing output people don't want to see18:15
corvusi'm with mordred: pylint has never produced useful output :)18:15
mordredso - I really think that's a red herring here - sure, it may be a valid use case but it's _certainly_ an edge case if it is18:16
mnaserrealistically, the job was going to fail anyways, so reporting it in console log vs in-line is going to yield same results (if using depends-on)18:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-openshift to ensure-openshift for consistency  https://review.opendev.org/71667518:16
mordredlet's start with "I run jobs that produce output I care about and I'd like to see it in the most efficient manner possible"18:16
mordredwhich si what I think inline comments from zuul aim to help with18:16
mordredpeople are _always_ going to do other weird things, and that's also ok18:16
clarkbits not just pylint fwiw18:17
mordredI know18:17
clarkbairship is apparently doing similar with coverage jobs now18:17
mordredI'm just saying - let's see if we can solve the actual case before going off and worrying about other things other people have decided they might want to do18:17
clarkband I think kata does it to walk commits in PRs and accumulate commit specific things18:17
mordredI don't care what kata wants to do with anything18:17
clarkbmordred: my point is its a general class of thing people do here18:18
clarkbregardless of project or tool18:18
mordred'I recognize that18:18
corvusmnaser: can you repeat your test with gerrit master, maybe on this change: https://gerrit-review.googlesource.com/c/zuul/ops/+/26103218:18
mordredclarkb: but what I'm saying is let's not hamstring the straightforward use case because there is _another_ use case where it might not make sense and where inline comments themselves might just make more sense to be disabled altogether18:18
mordredwe don't have a story for those cases at all right now18:18
mordredso solving them is completely orthogonal to this18:19
mnasercorvus: sorry, i don't think i follow, do you mean the whole "comment on a file that doesn't exist" thing ?18:19
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-devstack to ensure-devstack for consistency  https://review.opendev.org/71668518:19
clarkbmordred: ok18:19
corvusmnaser: yep, i want to find out if that will still work in the future18:19
mnasercorvus: good idea, i also wanted to think of github too as a case as well18:19
clarkbmordred: taking corvus' change stack example I think I'd personally prefer errors closest to the source18:19
clarkbwe'll end up with very noisy comments and change histories otherwise18:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-javascript-packages to ensure-javascript-packages for consistency  https://review.opendev.org/71668718:20
mordredcorvus: done18:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-nodejs to ensure-nodejs for consistency  https://review.opendev.org/71669218:20
mordredcorvus: I left a comment on nodepool.yaml18:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-yarn to ensure-yarn for consistency  https://review.opendev.org/71669318:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-pdk-dependencies to ensure-pdk-dependencies for consistency  https://review.opendev.org/71669518:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-if-python to ensure-if-python for consistency  https://review.opendev.org/71669818:20
mordredclarkb: yeah - this is where I thnk it might need to be configurable18:20
mordredclarkb: becuase I _strongly_ disagree with your preference there :)18:20
mordredon a project I had control over, I would want to see all of the errors on all of the files18:20
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666318:21
mordredbut I can understand that you might not agree18:21
mnasercorvus: looks like mordred did it and i also did it as well18:21
clarkbmordred: the reason for me preference is I don't want to mistakenly fix it in a child change, then have to fix it in the parent18:21
clarkbmordred: because the comments will indicate that I need to fix it in the child18:21
clarkbmnaser: then I've got some ugly rebasing and the chagne history gets weird18:21
mnaserclarkb: but in that case, the job will also indicate you need to fix it in the child?18:21
mordredclarkb: sure - totally understand. I just have a different preference18:21
clarkbthe end result will still be fine, but getting there will be a mess18:21
mordredand I think it will be cleaner and easier to see reported everywhere, at least personally18:21
clarkbmnaser: yes thats the problem. It shouldn't be fixed in the child it should be fixed in the parent where the issue originates18:21
mnaserclarkb: assuming we can identify that everywhere, which we cannot18:22
mordredfor me what I want is to present the information that the build has produced in a streamlined way18:22
mnaserso at least having it inline can be easy for someone to reply and say "i didn't touch this, i didn't break this"18:22
corvusyes, it's true that the log output for the job will say that the file needs to be changed.  however, by adding the comment to the change, you're going to make the file appear in the gerrit UI when it did not before.  that may, for some people, give them a moment of confusion since they may not understand why a file they don't remember editing is suddenly appearing in the changeset.18:22
clarkbmnaser: yes, I'm willing to deal with corner cases liek changing tox.ini or compiler flags directly to avoid that problem18:22
mordredif the build of eafch patch is showing all of the failures, then all of the failure are valid for each patch18:22
mnaseri think we have to remember that for the typical zuul user, they would be far more confused as to "why did i not get any comments, is something broken?"18:23
mnaserwe can discuss this for a long time but if it's not feasible in a very simple way, i worry that we cant go far :(18:23
mordredthis is a good point :)18:23
mnaseresp if that filtering happens in the zuul-scheduler layer18:23
corvusi think i'm sold on the idea that "a compiler flag change should show you all the compiler errors".  i'm less sold on "it's intuitive for files not changed to appear in the gerrit ui list of changed files"18:23
mnaseri think the only way that can even be possible is if the executor did the filtering of the zuul comments18:24
mnaserand the scheduler passed it directly through18:24
fungizuul will still report the job failure18:24
mnaserif that's never going to be an acceptable approach, we might have to all be sad that things would have to stay as is18:24
corvusi guess i'm not following the conversation; i'm not sure how we got to "implementation may not be possible"18:25
corvusi'm still at "is the ux desirable?"18:25
mordredcorvus: I wonder if it might be a difference in how we use gerrit? for me, a comment about where a failure is on a line in the review is so much quicker for me to see and understand what I need to go do it's worth it to me18:25
fungii imagine up-reving flake8/pycodestyle and having gerrit suddenly display hundreds of files in its browser for that change because they all have the wrong flavor of whitespace18:25
mordredbut I can totally imagine that people with other interactive workflows might not have that experience18:26
fungii'd much rather just look at the job log in that case18:26
corvusmordred: let's just say i accept your argument there.18:26
corvusmordred: can you evaluate my supposition that files not in the change appearing in the gerrit ui as if they were changed files may not be intuitive?18:26
mordredcorvus: totaly - I can totally imagine that that could be the case for someone18:27
mordredthis is why I think this might be one of those project-workflow differences choices areas (ignoring implementatino) ... because I could see a given zuul user breaking either way on the cost/benefit of those two things18:27
*** gmann_lunch is now known as gmann18:28
*** sugaar has quit IRC18:28
mordred(or really a given project manager, not really possible on a per-developer basis to have such an opinion)18:28
corvusmordred: the tricky thing is that i think this crosses over a bit from "preference of the project" to "preference of the individual reviewer"18:28
corvuslike, if the project manager decides that errors on untouched files should be reported as inline comments (a sensible workflow decision), they have also decided that every reviewer will lose the ability to quickly identify what files are touched by a change18:29
mordredyeah, that is totally true18:30
corvusmaybe that's an okay trade-off?  maybe users will get used to it and it won't bother them?  but it may be putting us in a place where gerrit does not behave in the way it "normally" behaves.18:30
mordredotoh - a project manager that decides to not allow the inline comments on untouched files may have reviewers/developers fix the things reported and then still get a failued on the next patch and have to go digging through logs wondering what happened18:31
mordredyah - it's not a straightforward call18:32
corvusmordred: yep.  and perhaps considering that *this* is also an edge case may be useful -- again, normally you're not going to trigger a comment-storm in a typical patch.  only new or updated linters/compiler settings/libraries are going to do that.  usually.18:32
mordredyeah18:33
mordredat least, one hopes it's not a normal thing :)18:33
corvus(discounting pylint, of course)18:33
mordredcorvus: maybe we should suggest to Alice a robot-comments feature to allow a user to set a preference of whether to display robot comments for files not in a change18:33
clarkbsetting them apart in the files diff view might be a good idea18:34
corvusmordred: yes, and if disabled, it would not expand the list of files18:34
mordredcorvus: ++18:34
mordredclarkb: robot comments are a new structure in newer gerrit apart from human comments18:34
*** hashar is now known as hasharBreak18:34
mordredwhich is cool18:34
clarkbthey are still inline though right?18:35
corvusmnaser: i'm pretty sure we'd have everything needed to set this as a job option and adjust behavior in the reporter in the scheduler.18:35
clarkband files diff is one page now18:35
clarkbI think you want to separate the files as in commit and out of commit there18:35
mordredI disagree :)18:35
mordredI want to see it all in as few clicks as humanly possible18:35
clarkbone page is fine18:35
clarkbbut do two stacks18:35
corvusyeah, you could separate without clicking18:36
clarkbno extra clicking18:36
mordredah - yes! that would be great18:36
mordredtotally agree18:36
mordredI think that would be a nice improvement to RC18:36
corvusmnaser, mordred: this is why we added the filtering: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-10-18.log.html#t2018-10-18T11:12:3818:37
corvusso it seems that the way that zuul is posting the comments does result in a gerrit error (notwithstanding that doing something similar through the webui does not)18:38
mordredcorvus: fascinating18:38
corvusso step 1 would be to solve that api issue18:38
mordredyeah18:38
mordredcorvus: turns out removing the filtering without fixing the API issue would not be an improvement18:38
corvusoh... it *could* be that gerrit might accept a comment on a file if the file exists in the repo in that commit?  but in this case we were sending garbage filenames and that's an error?18:39
corvusstill, we'd want to confirm the exect behavior and validate the idea18:39
mordredcorvus: that would make sense18:39
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672218:40
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Test doc file comments  https://review.opendev.org/71668018:40
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-docker to ensure-docker for consistency  https://review.opendev.org/71666318:42
corvusmordred, mnaser: to summarize my position: i agree that there are valid use cases for 'inline all the comments'.  i'm suspicious that doing that by default would be a good UX in gerrit, but i'm not convinced it's bad and would be willing to experiment with it in opendev.  i'd be okay adding it as an option (probably off by default to start?) to jobs, but we need to perform some testing against the gerrit api18:45
corvusto validate it first.18:45
corvusclarkb: ^18:45
clarkbthat seems reasonable18:46
clarkbmaybe dog food in zuul for a bit before exposing it broadly18:46
mordred++18:46
mordredcorvus: I agree with all of those words18:46
fungii have at times hit new releases of style checkers which suddenly start complaining about nearly every file in your project, so i can see where that could sometimes blow up on you18:47
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Test doc file comments  https://review.opendev.org/71668018:49
corvusfungi: yep.  i think there's still disagreement on whether inlining all the comments in that case is "good" or "bad".  i'm comfortable with differing opinions on that and having zuul support those differing opinions.  there is a very nuanced distinction between showing those comments inline and the thing i'm concerned about (the list of files).18:49
corvusif we (optionally) support it, we'll get feedback on both parts of that (whether having the comments inline is useful or confusing, and whether having the file list expand is confusing or irrelevant)18:50
mordred++18:51
corvusmnaser: we also can write superuser blog posts18:57
corvus(i feel like that's orthogonal to "zuul-ci.org should have a blog"; i don't mean to suggest that as an alternative, just something to keep in mind as an additional channel)18:57
mordred++18:59
*** harrymichal has quit IRC19:07
*** harrymichal has joined #zuul19:07
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645219:08
mnasercorvus: yes i agree in also "syndicating" that content as well19:12
mnasercorvus, mordred: i'm in agreement with the state of things right now, but yeah, we'd have to figure out the gerrit bits (i suspect it has to do with commenting on a non-existing file) and then all the code in place19:12
mnaseruntil then i am in revision six million for inline stuff for golang19:13
mnaserthis ain't easy19:13
mnaserwhich also means i am about to give up and just write unit tests for all of our sakes19:13
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-kubernetes to ensure-kubernetes for consistency  https://review.opendev.org/71666719:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-openshift to ensure-openshift for consistency  https://review.opendev.org/71667519:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-podman to ensure-podman for consistency  https://review.opendev.org/71668219:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-devstack to ensure-devstack for consistency  https://review.opendev.org/71668519:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-javascript-packages to ensure-javascript-packages for consistency  https://review.opendev.org/71668719:15
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-nodejs to ensure-nodejs for consistency  https://review.opendev.org/71669219:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-yarn to ensure-yarn for consistency  https://review.opendev.org/71669319:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-pdk-dependencies to ensure-pdk-dependencies for consistency  https://review.opendev.org/71669519:16
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-if-python to ensure-if-python for consistency  https://review.opendev.org/71669819:16
avassI think most of it should work now19:17
avassnot sure why this change complains about invalid configuration though: https://review.opendev.org/#/c/716675/19:18
AJaegermordred: previously, if tox fails, I could open the Console tab and it would open at "tox: Run tox". Now "Tox: Return tox status" shows failed. and "Run tox" shows changed. can we change that back?19:20
AJaegerExample: https://zuul.opendev.org/t/openstack/build/96de28817cd84bd5aa183015b51ca855/console19:20
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Support multiple matchers when parsing tox output  https://review.opendev.org/71626319:27
*** bhavikdbavishi has quit IRC19:27
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626419:27
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672219:27
mordredAJaeger: oh hrm. that is a bother19:27
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-nodejs to ensure-nodejs for consistency  https://review.opendev.org/71669219:28
mordredAJaeger: it's related to how the tox output processing is working ... I agree, that's nonideal - we'll need to ponder on it for just a bit to find a proper solution19:28
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-yarn to ensure-yarn for consistency  https://review.opendev.org/71669319:29
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Keep error status in tox run  https://review.opendev.org/71673619:33
tobiashmordred, AJaeger: this might make that console issue better ^19:33
AJaegerthanks!19:33
mordredtobiash: that is much smarter than where my brain was taking me19:38
corvustobiash: +2 with comment, what do you think?19:39
tobiashmordred: any idea why this misses the debug task after  "look for output": https://0f32d14684fb053eca08-e68f967f18214a0d1e6eb98f4cfddc91.ssl.cf5.rackcdn.com/716680/3/check/zuul-tox-docs/f708016/job-output.txt ?19:39
tobiashmordred: the depends on adds such a debug task directly afterwards19:39
tobiashmordred: yeah, I'll add  a comment19:40
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Keep error status in tox run  https://review.opendev.org/71673619:42
tobiashmordred: found it:       - '<Job zuul-tox-docs branches: None source: zuul/project-config/zuul.d/jobs.yaml@master#1>'19:45
tobiashmordred: do you know why zuul-tox-docs is defined in project-config?19:46
tobiashthat makes that job non-speculative19:46
tobiashwhich explains why my sphinx line comment changes don't work19:46
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Test doc file comments  https://review.opendev.org/71668019:48
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626419:51
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672219:51
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-pdk-dependencies to ensure-pdk-dependencies for consistency  https://review.opendev.org/71669519:52
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Rename install-if-python to ensure-if-python for consistency  https://review.opendev.org/71669819:52
openstackgerritMerged zuul/zuul-jobs master: Keep error status in tox run  https://review.opendev.org/71673619:56
tobiashAJaeger: fyi ^19:56
*** hasharBreak is now known as hashar19:57
openstackgerritJames E. Blair proposed zuul/zuul-registry master: Add debug/verification for uploads  https://review.opendev.org/71644419:57
avassmordred, corvus: I cannot figure out why these changes "depends on a change with invalid confiuguration": https://review.opendev.org/#/c/716675/4 https://review.opendev.org/#/c/716695/ https://review.opendev.org/#/c/716692/19:58
corvusavass: hrm, i'll see if there's anything in the logs19:58
corvuszuul-maint: is anyone else interested in reviewing a not-too-complicated zuul-registry change?  i'd like to get   https://review.opendev.org/716444 merged so it's in place the next time the problem shows up19:59
avasscorvus: yeah that error could have been a bit more specific19:59
corvusavass: yep, it's usually more obvious :/19:59
*** weshay is now known as weshay|ruck20:00
corvusavass: it's a bug in zuul: AttributeError: 'NoneType' object has no attribute 'loading_errors'20:00
corvusavass: i think there's a patch; lemme see if i can find it and if it's landed20:01
tobiashcorvus: that sounds familiar20:01
corvushttps://review.opendev.org/71254420:01
corvusclarkb: ^20:01
corvusyep that's the right error20:01
tobiashcorvus: shall we land that or first try to find out why the parent layout is None?20:02
corvustobiash: i don't understand the fix yet, so i don't want to land it20:03
tobiashme too20:03
clarkbI thik we decided my change wasnt right in earlier conversation20:03
clarkbya20:03
corvusavass: i'm pretty sure a recheck once the queue is clear will work20:03
corvusclarkb: oh, maybe we should dig up that convo and paste it into gerrit :)20:03
clarkbI'm hesitant too and that change was mostly to leave a breadcrumb with stab at problem20:03
tobiashthat would help :)20:03
avasscorvus: alright I'll wait a bit then :)20:04
corvusclarkb, tobiash, avass: http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2020-03-17.log.html#t2020-03-17T23:14:3420:05
AJaegertobiash: cool20:05
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Test doc file comments  https://review.opendev.org/71668020:05
corvusthere's no gate pipeline involved here, so that may reduce the search space for the problem somewhat20:06
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Update registry test to use ensure-podman and ensure-docker  https://review.opendev.org/71675220:06
fungizuul-maint: in case it slipped past you like it did me, the osf "community meeting" conference call tomorrow is intended to feature project updates, which means zuul: http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-April/001202.html20:07
fungiit turns out the meeting organizers are looking for ~5 minutes of updates on what's been going on with zuul in the 5 months since corvus's project update in shanghai20:07
fungii started a brainstorming etherpad here and clarkb and jamesmacarthur have also suggested some content for a slide, but nothing's carved in stone: https://etherpad.openstack.org/p/zuul-2020q1-update20:07
fungiif anybody knows of things which should be included, or wants to volunteer to talk for 5 minutes on the call about whatever winds up in the slide, that's awesome20:08
corvusfungi: looks good20:09
tobiashcorvus, fungi: shall we add github checks api support?20:10
fungii guess that landed since november?20:11
tobiashyes, that landed recently20:11
fungigerrit checks api too, right?20:11
fungior i guess that's still in flux?20:11
corvusgerrit checks is 'experimental'20:12
corvusgithub checks is more solid20:12
tobiashbut not yet feature complete as well20:12
mnasergreat20:13
mnaseri have functioning unit tests20:13
mnaserbut now i get to have the fun of long strings and pep8.20:13
*** sgw has quit IRC20:14
*** harrymichal has quit IRC20:17
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645220:18
corvusavass: it might be worth a quick note to the zuul-discuss list to lest folks know about the install -> ensure effort to make sure we've got consensus (i'd hate to merge all those and then have folks say "maybe we should have done ... instead")20:18
mnasermordred, corvus: these are unit tests for the golangci-lint job, maybe it can serve as a good example for doing the tox ones... i am at a bit of a loss of whats a clean way of keeping it under 80 characters without making the string-y bits super confusing20:19
mnasertobiash: ^20:19
fungicorvus: tobiash: thanks, so "support for the github checks api" is how we'd refer to it i guess?20:20
corvusfungi: ++  or "support for github checks"20:21
tobiashbtw, this includes file comments :)20:21
tobiashwhich is why this recently became much more interesting for me ;)20:22
corvusmnaser: one crazy idea: save the strings in a $(yaml|json|csv|whatever) file and have each unit test call a function to return the correct string from the fixture file20:22
fungicorvus: got it, i tried to infer terminology from the connection driver docs but it uses "check" and "checks" in fairly disconnected ways20:22
corvusfungi: yeah, "checks" is the common name of the feature in github20:22
fungitrying to figure out a way to not make it sound like we only just added support for github itself, since checks is such a generic term20:23
fungisupport for github's checks feature?20:23
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626420:23
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672220:23
corvusmnaser: getting the weirdly formatted text out of the functions might make them easier to read (at the risk of having to look elsewhere for the data)20:23
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Don't silently ignore exceptions when parsing tox output  https://review.opendev.org/71676620:23
corvusfungi: ++20:23
avasscorvus: yeah I agree, just wanted those changes to be ready20:24
mnasercorvus: you know i was mulling over that and now that you said it out loud, that makes me feel better about that too20:24
corvusmnaser: great minds20:24
*** igordc has joined #zuul20:27
avassIt's getting pretty late here, I'll check in tomorrow20:27
* tobiash totally overlooked the clock20:28
avasshaha, yeah same here20:28
*** avass has quit IRC20:29
*** y2kenny has joined #zuul20:29
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Support multiple matchers when parsing tox output  https://review.opendev.org/71626320:32
y2kennyHi, I ran into some exception about MergeJob object has no attribute updated on scheduler loadconfig:20:32
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Don't silently ignore exceptions when parsing tox output  https://review.opendev.org/71676620:32
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626420:32
y2kennyhttp://paste.openstack.org/show/791487/20:32
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672220:32
*** sgw has joined #zuul20:33
tobiashy2kenny: that can occur if there is no merger in the system or the merger hits a timeout when cloning a large repo20:34
corvusy2kenny: that's obviously not a great error and we should improve that; but it may be caused by a problem on an executor or merger which handled the job; you might be able to find more info if you look at their logs20:34
y2kennyok so that in itself shouldn't prevent the config from loading right?20:34
y2kennyyour description sounds right because I didn't start any executor or merger for a long time20:35
corvusy2kenny: that's how zuul loads its config (by asking the executors/mergers to do it for it), so an error there (espcially at server start) is unrecoverable20:35
fungiis this related to the situation mnaser encountered where starting the scheduler before the executors/mergers causes it to not load its configuration?20:36
y2kennyum... so I should start an executor before scheduler20:36
y2kennythat explains it20:36
tobiashfungi: yes20:36
corvusy2kenny: it should be enough to start them at around the same time.  but yeah, not long before, or the scheduler will timeout waiting.20:36
fungiand the suggestion for the kubernetes operator is to orchestrate the start order, right?20:37
y2kennycorvus: I am still trying to do things the hard way :).20:37
y2kennyI was just doing the last bit of moving the scheduler onto k8s w/o using the operator or helm20:37
tobiashfungi: yes, I think tristanC already has a patch up for that20:37
fungioh, cool20:38
corvusfungi: i think the k8s operator takes the "start them all around the same time" approach; *restarting* is a slightly different question which tristanC has a patch up for20:38
y2kennyI got executor, nodepool, web on my k8s cluster... just missing the scheduler20:38
fungiahh, i can see where restart order can be an issue20:38
y2kennyright now I am doing all of them in a bunch of yaml files20:38
corvusfungi: (specifically in the case of a restart with an updated config, the mergers/executors need to start with the new config before the scheduler does)20:39
fungiyep, makes sense20:39
y2kennycorvus: that's good to know... I was wondering what I needed to do when I change the config20:39
corvusy2kenny: that's the case for a change to zuul.conf, like to add a connection20:39
corvusy2kenny: a main.yaml (tenant config) change doesn't need any restart, just a "smart-reconfiguration".20:40
y2kennyso far I have  been restarting pretty much everything... with docker compose20:40
y2kennyah ok.  That's good to know about the tenant config20:41
*** avass has joined #zuul20:41
y2kennydoes this mean the docker compose for the quick start is a bit misleading?20:44
y2kennythe executor container has a depends_on scheduler instead of the other way around20:44
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: Strip source dir from file comments  https://review.opendev.org/71626420:45
openstackgerritTobias Henkel proposed zuul/zuul-jobs master: DNM: Debug sphinx message  https://review.opendev.org/71672220:46
tobiashcorvus, mordred: first sphinx line comment: https://review.opendev.org/#/c/716680/5/doc/source/howtos/gerrit_setup.rst20:54
tobiash:)20:54
corvustobiash: nice!20:55
mordredtobiash: that is awesome20:58
corvusmordred, mnaser: thinking further on the line comments for invalid file thing: jhesketh suggested a change to that warning message to include the comment.  we could look at that as a way to get the info to the user without altering the gerrit ui.  it wouldn't be inline comments, but they'd appear in the overall change message, which, with most gerrit uis displaying the inline comments with the change20:58
corvusmessage, is a very likely place for people to read them anyway).  maybe that's a half-step we could take that doesn't open up as many ui questions?20:58
*** avass has quit IRC20:59
mordredcorvus: seems like a decent step forward - especially since the warning message isn't as friendly to the user (it's a base job sending the data, there's nothing they can do about it)20:59
mordredAJaeger: check out https://review.opendev.org/#/c/716680/5/doc/source/howtos/gerrit_setup.rst from tobiash  above21:00
corvusmordred, mnaser: here's a gertty sketch of what i'm talking about might look like (should be about the same in gerrit web ui): http://paste.openstack.org/show/791491/21:00
mordredcorvus: maybe instead of Warning: more like "Issues in files not in this change:" or something?21:02
mordredbut not that - those are terrible words21:02
mordredlargely I like the idea21:02
corvusmordred: yeah, the warning is a generic header, but we can probably do something about that21:04
corvus(like, the current implementation adds an entry to the list of warnings for the item)21:04
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645221:05
mnasercorvus: yeah i like that21:06
mnasercorvus, mordred, tobiash: i havecome up with "somewhat" of a framework to testing our "outputs" in the golangci-lint stuff21:06
mnaserwe can probably reuse that, and all we really need to do is create a yaml file with data, workdir and expected output comments21:07
clarkbsomewhat orthogonal but I thought golang had a built in linter21:07
clarkbliek you didn't need to do anything it just forced it on everyone21:07
tobiashmnaser: cool a file comments parser test framework :)21:08
y2kennyclarkb: are you thinking about go fmt?21:08
mnaserclarkb: it does, but golangci-lint is kindof say.. similar to pylint where it combines a bunch of the most popular ones like static checks etc etc all into one package21:08
mnasertobiash: yep, just need to figure out how to put it somewhere more 'central' in the repo as a next step and i think that will make testing the tox one very trivial :D21:08
clarkbmnaser: gotcha so its more extensive than the default21:09
mnaserclarkb: yep :)21:09
tobiashmnaser: zuul-jobs has a tests dir in its root. I think that might be a good central place for central parts21:10
mnasertobiash: can we import that from the role library tests somehow?21:11
tobiashmnaser: that's the question, but we have __init__.py files in the whole chain from root to test file in the module21:11
tobiashso it might be as easy as 'import tests.foo'21:12
tobiashstestr runs from the root appearently so I think it should just work21:13
mnaserlet me try locally quickly21:13
*** y2kenny has quit IRC21:13
mnaseroh yeah i got it21:17
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645221:18
tobiash:)21:18
mnasertobiash: ^ that worked :) thanks!  this is shaping up nicely21:18
openstackgerritMerged zuul/zuul-registry master: Add debug/verification for uploads  https://review.opendev.org/71644421:22
tobiashmnaser: added a question21:22
mnasertobiash: ah yes, good catch21:23
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645221:27
mnasertobiash: finally.  that should be it.  i also cleaned up the yaml load warnings too21:27
tobiashmnaser: one comment, lgtm apart from that21:29
openstackgerritMohammed Naser proposed zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645221:31
mnasertobiash: thanks, addressed :)21:31
tobiashlgtm21:31
mnaserwoot, i'm excited, that should make it easy to write tests for the tox based one now without worrying that we broke things21:32
tobiashyeah, I'll look into that tomorrow probably if no one else gets bored ;)21:32
corvusmnaser: i like that, you keep the input/expected output in the same place (the yaml file)21:32
mnasercorvus: yep, and the generator code means no "hey you forgot to create a test but created a file" or lots of repeated stuff21:33
mnaserone place to look when it breaks21:33
mnasertobiash: cool! look forward for that :) i'll get back to dealing with other stuff for now :)21:34
*** y2kenny has joined #zuul21:49
*** frickler_ has joined #zuul22:03
corvusmnaser: want any more review on that or should i push it through?22:04
*** aspiers has quit IRC22:08
*** frickler has quit IRC22:08
*** rlandy is now known as rlandy|brb22:12
*** aspiers has joined #zuul22:19
openstackgerritMerged zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575622:49
*** rlandy|brb is now known as rlandy22:58
*** hashar has quit IRC22:59
*** tosky has quit IRC23:03
mnasercorvus: no i think it's actually good, i'm happy with the state of it23:43
corvusdone23:44
mnasercorvus: yay, awesome.23:44
openstackgerritMerged zuul/zuul-jobs master: golangci-lint: add job  https://review.opendev.org/71645223:56
*** rlandy has quit IRC23:58
*** sshnaidm is now known as sshnaidm|afk23:59

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