Friday, 2020-11-06

*** wuchunyang has joined #zuul00:15
*** wuchunyang has quit IRC00:19
*** ikhan has joined #zuul00:20
*** iurygregory has quit IRC01:26
*** zenkuro has quit IRC02:01
*** zenkuro has joined #zuul02:02
*** ikhan has quit IRC02:28
*** Goneri has quit IRC02:31
*** zenkuro has quit IRC02:43
*** zenkuro has joined #zuul02:43
*** bhavikdbavishi has joined #zuul03:08
*** bhavikdbavishi has quit IRC03:59
*** bhavikdbavishi1 has joined #zuul03:59
*** bhavikdbavishi1 has quit IRC04:00
*** bhavikdbavishi has joined #zuul04:00
*** wuchunyang has joined #zuul04:02
*** wuchunyang has quit IRC04:07
*** zenkuro has quit IRC05:07
*** vishalmanchanda has joined #zuul05:32
*** evrardjp has quit IRC05:33
*** evrardjp has joined #zuul05:33
*** wuchunyang has joined #zuul05:45
*** zenkuro has joined #zuul06:10
*** bhavikdbavishi has quit IRC06:18
*** bhavikdbavishi has joined #zuul06:20
*** bhavikdbavishi has quit IRC06:45
*** rpittau|afk is now known as rpittau06:47
ianwfelixedel: we should skip tasks that fail but are failed_when: false like in https://zuul.opendev.org/t/pypa/build/248c7f4eef274cf5ac7fc8c15f42a598 (https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L7)07:08
felixedelianw: What do you mean?07:16
ianwfelixedel: if you look at the task summary page, it shows that task as failed, when it was supposed to fail but we ignore it07:17
ianwit's a bit confusing07:17
ianwthere's two there, checking if tox and pip are installed07:17
felixedelAh, task summary. Yes that would be an improvement07:18
felixedelSo in case of the pypa-pip-py38 the build failed, but only due to one task and not to all three, right?07:19
*** bhavikdbavishi has joined #zuul07:20
ianwthat's right, just the last one (the tox failure)07:20
felixedelok. Btw, I like the new design with the red cross and the bold task and host names. IMHO much better readable than the previous version ;-)07:22
tobiashianw: I've responded on https://review.opendev.org/756325 (dib in venv)07:24
*** zenkuro has quit IRC07:35
*** zenkuro has joined #zuul07:35
*** jcapitao has joined #zuul07:42
openstackgerritFelix Edel proposed zuul/zuul master: UI: Remove stretchable link from build and buildset table  https://review.opendev.org/76162107:57
openstackgerritFelix Edel proposed zuul/zuul master: UI: Remove stretchable link from build and buildset table  https://review.opendev.org/76162107:59
*** iurygregory_ has joined #zuul08:09
*** iurygregory_ is now known as iurygregory08:14
openstackgerritDaniel Pawlik proposed zuul/zuul master: Improve Elasticsearch reporter doc and driver, changed index name  https://review.opendev.org/76144108:19
*** jcapitao has quit IRC08:53
*** jcapitao has joined #zuul08:55
*** bhavikdbavishi has quit IRC08:56
*** jpena|off is now known as jpena08:57
*** bhavikdbavishi has joined #zuul09:01
*** jcapitao is now known as jcapitao_afk09:02
*** jcapitao_afk is now known as jcapitao09:39
*** jcapitao has quit IRC09:44
*** jcapitao has joined #zuul09:46
openstackgerritDaniel Pawlik proposed zuul/zuul master: Improve Elasticsearch reporter doc and driver, changed index name  https://review.opendev.org/76144109:48
*** bhavikdbavishi has quit IRC09:51
*** wuchunyang has quit IRC10:25
*** wuchunyang has joined #zuul10:26
*** wuchunyang has quit IRC10:32
*** jfoufas1 has joined #zuul10:33
zbrtobiash: felixedel: https://review.opendev.org/#/c/761293/ please, very simple.10:44
*** bhavikdbavishi has joined #zuul10:49
*** hashar has joined #zuul10:54
*** wuchunyang has joined #zuul11:09
*** bhavikdbavishi has quit IRC11:16
avasstristanC: can you take a look at zbr's change ^ ?11:49
*** jcapitao is now known as jcapitao_lunch11:49
zbr0755/0644 are not default, is likely implicit but not default. there is no documented default for any  "mode" in ansible modules11:51
zbrin fact that was one of the reasons why E208 was created11:51
zbravass: there are still open (unresolved) bugs on ansible related to the file modes, and i got confirmation from bcoca few days ago that explicit is recomanded.11:54
zbrin fact it is recommended inside the source code of ansible to be explicit11:54
*** wuchunyang has quit IRC12:00
*** rfolco has joined #zuul12:06
*** bhavikdbavishi has joined #zuul12:19
*** jpena is now known as jpena|lunch12:36
openstackgerritSimon Westphahl proposed zuul/zuul master: Implementation of Zookeeper backed event queues  https://review.opendev.org/76117012:39
openstackgerritSimon Westphahl proposed zuul/zuul master: Implementation of Zookeeper event watcher  https://review.opendev.org/76117112:39
openstackgerritSimon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed trigger event queues  https://review.opendev.org/76117212:39
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Switch to Zookeeper backed management event queues  https://review.opendev.org/76173812:39
tristanCzbr: if they are not the default values, when are they not used? In other words, how ansible decide which values to use?12:47
zbrtristanC: sorry to say, but I found your questions bit... draining. Whatever explanation I gave you already found another question to ask.12:54
zbrwhen i posted link to https://github.com/ansible/ansible/issues/67794 i did not get any reply12:54
zbrthat is from yesterday from #ansible-deve channel: https://sbarnea.com/ss/Screen-Shot-2020-11-06-12-55-11.49.png12:57
*** jcapitao_lunch is now known as jcapitao12:59
zbrand to repeat for the n-time: defaults are not documeted in ansible and they are like this for a good reason: they do not yet know what to say about them and they are subject to change, as they were already changed several times during this year.13:00
*** tosky has joined #zuul13:07
tristanCzbr: if i understand the issue 67794 correctly, the default mode value is world readable unless a non default umask is set on the target system?13:19
tristanCzbr: i'm sorry to keep on asking, but i'm not familiar with ansible internal and that bug report is hard to read. I am looking for a more simple reason to respect the 208 rule, which i find quite intrusive considering the amount of task that relies on ansible default behavior13:23
*** bhavikdbavishi has quit IRC13:27
*** jpena|lunch is now known as jpena13:32
zbrtristanC: attempt to resume it: in order to avoid potentially security issues is better to be explicit on file mode everywhere. this forces the playbook writer to think twice.13:48
zbryep, likely the number of places where non default permissions are needed is <10%, based on zuul-jobs repo which had >100 occurences.13:49
zbrit is impossible for the linter to guess where security matters or not, so the approach is to be always explicit.13:50
zbrmost of the time is 0755/0644, but as we seen with current patches we keep discovering tricky areas where it should not be.13:51
fungibut is it the job of a syntax linter to warn you about possible security blind spots?13:51
zbrfungi: do you think that using lowercase L letter as variable name is good practice?13:51
zbrmore recent versions of flake8 made it an error too, it fits the same use-case. While the code may not be broken as it is, it may become broken in the future.13:53
zbrthere is wide range of categories of issues that are spotted, some are style, readability, deprecations, security, idempotence,... in the end a human needs to decide what to act on or not.13:54
zbrIMHO, even if we have a single case of too relaxed permissions it would count as a good enough case to use it.13:55
zbras an anecdote, I do remember few years back there were people arguing that adding "name" to all ansible tasks tasks made no sense, as they were self-explanatory.13:57
zbrlucky, i do not see these kind of comments anymore.13:57
fungiit just seems like the main concern with 208 is that, since the linter can't know what the "correct" permissions are for a file, sure it's possible you forgot to set strict permissions on something but it's just as possible that you explicitly set incorrect permissions (i saw that in puppet all the time when people would cut and paste another resource and change a few details)13:59
fungiforcing someone to set permissions doesn't necessarily increase the chances that they choose the correct permissions14:00
zbrif unsure you can always add a "# noqa: 208" comment to silence it.14:01
avasstosky: you don't happen to have a way around windows double-hop security thingy with certificate authentication?14:07
avasstobiash: whoops ^14:08
toskynp :)14:08
avasstobiash: the fix to use multiple disk letters in 740110 works on our cloud nodes where we don't need it but not on our on-prem ones where we actually need it since it's not allowed to check UNC paths (//localhost/c$/...).14:11
tobiashavass: what do you mean with double-hop?14:11
fungizbr: originally i thought the point of 208 was to ease the upcoming default transition. there was that regression where ansible tried to resolve a (key permissions related?) issue by making file resources no longer rely on umask and instead always default to o0600 which broke horribly for lots of folks, so they resolved to only do that in a later release instead but would need to get everyone to start being14:12
fungimore explicit about their permissions instead of relying on the default to allow the default to be changed gracefully?14:12
zbrfungi: true. still, be aware that it is likely to see future changes from ansible in that area.14:14
zbrthey made several changes but the subject it not closed14:14
avasstobiash: I believe it's this: https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-714:15
fungiright, that's what i'm saying, if the point of 208 is to make sure that our file resources are forward-compatible with future ansible release plans to change the default mode, then that seems like a better reason to rely on it. the "but security!" argument is fairly hollow14:15
avassi wouldn't expect //localhost/ to check anything than the local machine but seems like it does (when it's connected to an AD network?)14:15
tobiashavass: I've never tried winrm multi hop14:19
avassme netiher, I guess it would just work if we didn't allow multiple drive letters14:20
openstackgerritFelix Edel proposed zuul/zuul master: UI: Disable links on skipped builds in build table  https://review.opendev.org/76174914:23
*** hashar has quit IRC14:23
*** jfoufas1 has quit IRC14:27
openstackgerritSimon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed trigger event queues  https://review.opendev.org/76117214:45
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Switch to Zookeeper backed management event queues  https://review.opendev.org/76173814:45
*** Goneri has joined #zuul14:46
pabelangermorning, so we in zuul.a.c are dealing with the issue of invalid tags in git repos.   Basically, people don't understand that deleting a git tag is bad, which is leading to missing sha1 in our zuul-mergers, and jobs fail to start because of it. I know we put in a fix for dangling head in git, could we do something to refresh git tags on failure?14:47
pabelangerit leads to a lot of manualy work to search all git cache for the deleted tag, to manually delete it14:47
swestpabelanger: there is a --prune-tags option for git, but IIRC that's only available in git >= 2.17.014:51
pabelangergit fetch --prune origin "+refs/tags/*:refs/tags/*"14:54
pabelangeris what I see14:54
pabelangerwhich did work locally14:54
pabelangerI wonder if we could do that periodically, or when we raise an exception14:55
swestgit fetch --prune --prune-tags origin14:55
pabelangerhttp://paste.openstack.org/show/799788/14:56
pabelangeris what we see14:56
avasspabelanger: I thought there already was a fix for that since we had the same problems like half a year ago14:57
avassmaybe our users actually listened14:57
avassyeah maybe I'm just misremembering14:58
pabelangeravass: it could be fixed, we are running 3.19.114:58
avassso are we :)14:58
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Prune also tags on fetch  https://review.opendev.org/76175615:02
swestpabelanger: ^ something like that might work15:02
pabelangerswest: thanks, I was just looking at that code15:03
*** vishalmanchanda has quit IRC15:12
avasstobiash: looks like you can get around it by installing a loopback adapter :^)15:15
*** rpittau is now known as rpittau|afk15:18
*** is_null has joined #zuul15:18
*** bhavikdbavishi has joined #zuul16:00
*** sshnaidm_ has joined #zuul16:12
*** sshnaidm|afk has quit IRC16:13
*** bhavikdbavishi has quit IRC16:15
*** bhavikdbavishi has joined #zuul16:19
*** sshnaidm_ is now known as sshnaidm|afk16:21
*** bhavikdbavishi has quit IRC16:23
openstackgerritMerged zuul/zuul-jobs master: More E208  https://review.opendev.org/76129316:25
*** jcapitao has quit IRC17:33
corvustristanC: want to +w https://review.opendev.org/728118 ?17:38
corvus(i think your comments are addressed)17:38
corvustobiash: ditto on https://review.opendev.org/75131217:40
corvustobiash: and https://review.opendev.org/75070917:44
*** jpena is now known as jpena|off18:02
openstackgerritMerged zuul/zuul-website master: Add link to zuul-client documentation  https://review.opendev.org/75131218:03
corvusmhu: i'm digging up the dockerhub secret and will update your change with it18:04
mhucorvus, nice thanks! Otherwise I'm fine with just having containers generated in the CI. Users can get zuul-client from pip and it's now packaged in Fedora 34.18:06
mhubut I won't mind another way to use the CLI18:06
corvusmhu: it's easy, and yeah, i could see "docker run" being a convenient way for folks to do it18:06
mhuplus I have to hand it to the opendev folks, it was super easy to create that docker image18:07
fungiawesome to hear18:08
openstackgerritJames E. Blair proposed zuul/zuul-client master: Add Dockerfile  https://review.opendev.org/75551918:11
corvusmhu: ^18:11
mhucorvus, thanks! LGTM if you're okay with it18:12
corvusheh i love we're building arm images of it too :)18:13
corvusmhu: though, that could slow things down.  do you think it's important?18:14
mhuthe arm images? I didn't even know about them :)18:15
corvus(i think we only do that for nodepool builders now, and that's so they can build arm images).  i guess we're asking whether we think we have many users using arm workstations...18:15
corvusmhu: i'll leave a comment18:15
clarkbin particular the package installation steps that run compiles are very slow in the emulated arm build env18:16
mhuright, I guess I iterated from an existing image build job and didn't notice the arm arch in the vars18:17
mhuI'm sure the people on arm workstations won't complain if we don't build an image for them18:18
openstackgerritMerged zuul/zuul-client master: Add encrypt subcommand  https://review.opendev.org/75070918:20
openstackgerritMatthieu Huin proposed zuul/zuul-client master: Add Dockerfile  https://review.opendev.org/75551918:20
corvusmhu: you can drop the whole arch section18:20
openstackgerritMatthieu Huin proposed zuul/zuul-client master: Add Dockerfile  https://review.opendev.org/75551918:21
mhucorvus: there you go18:21
corvustobiash: https://review.opendev.org/755519 is ready for +318:21
clarkbcorvus: if you're reviewing things https://review.opendev.org/#/c/761229/ would be good to rereview (I cleaned up logging since you last reviewed it)18:23
mhuthanks for the reviews, it's good to see that stuff getting merged! :)18:24
corvusclarkb: +3 mhu: sorry for the delay :)18:25
tobiashcorvus: added a question18:26
corvustobiash: right my fault; i undid the TODO comments wrong there18:28
corvustobiash, mhu: i'll fix18:28
fungiawesome that we've made it so easy to build multi-arch images you can even do it by accident ;)18:28
openstackgerritJames E. Blair proposed zuul/zuul-client master: Add Dockerfile  https://review.opendev.org/75551918:29
*** zenkuro has quit IRC18:38
*** zenkuro has joined #zuul18:38
openstackgerritMerged zuul/zuul-client master: Add Dockerfile  https://review.opendev.org/75551918:45
openstackgerritMerged zuul/zuul master: REST API: improve tenant scoping of autohold, authorizations  https://review.opendev.org/72811818:58
*** zenkuro has quit IRC19:02
openstackgerritMerged zuul/nodepool master: Have nodepool scan as many ssh host keys as possible  https://review.opendev.org/76122919:14
clarkbI'll restart an opendev launcher after lunch to ensure ^ is happy in prod andnot just testing19:16
fungithanks, i guess we also have users who can confirm it fixes the problem of nodes switching between host key types19:25
clarkbya19:28
*** vorotech has joined #zuul20:19
sean-k-mooneyshould depends on work between different triggers?21:08
sean-k-mooneye.g. can a github PR depend on a gerrit reivew21:08
fungiyes21:08
fungias long as those projects are included in the same tenant21:08
sean-k-mooneydid i do this wrong so https://github.com/SeanMooney/zuul-test/pull/4/commits21:09
sean-k-mooneyam they are21:09
fungicross-connection change/pr/mr dependencies should totally work21:09
clarkbeven if they are different tenants it will still work as far as preventing one from merging before the other goes21:10
clarkbI think21:10
sean-k-mooneyi wonder is this a branch thing http://paste.openstack.org/show/799803/ is my tenant config21:11
sean-k-mooneyoh21:11
tobiashsean-k-mooney: under github the depends on must be in the pr description, not commit message21:11
sean-k-mooneycoudl it be the load-branch... acutlly no21:11
sean-k-mooneytobiash: oh i did not know that21:12
sean-k-mooneyis that documetned somewhere21:12
* sean-k-mooney not that i read it too closely21:12
tobiashhttps://zuul-ci.org/docs/zuul/discussion/gating.html#cross-project-dependencies21:13
sean-k-mooneyah yes its in the note which i did not read21:14
sean-k-mooney:)21:14
sean-k-mooneyso like https://github.com/SeanMooney/zuul-test/pull/521:15
sean-k-mooneyyep got a node failure which is fine i dont have that label set up yet21:16
corvussean-k-mooney: congrats, you just did cross-source-dependencies :)21:21
sean-k-mooneyhehe yep is there a reason it does not work in the commit by the way21:22
sean-k-mooneyi mean its fine just wondering why not support both21:22
fungibecause zuul isn't triggered per commit for github, it's triggered by pull request, and also going back and altering commit messages in arbitrary commits within pull requests is frowned upon in some github workflows21:25
sean-k-mooneyah right21:26
sean-k-mooneythat makes sense when you say it21:26
corvus(you can put it in both of course, it'll just be ignored in the commit; if you do the github default of making the pr description from the commit, then that makes it easy)21:26
sean-k-mooneyyep i forgot to add it the first time then force pushed and then didnt see how to update the description21:27
sean-k-mooneyso i just created a second pr which auto populated and it worked21:27
sean-k-mooneypersonally i dont really like the PR workflow unless you treat it like gerrit and fix the change and force push the fixed version21:28
sean-k-mooneyi really hate the add patches on top to adress feedback appoch and just squash them21:28
sean-k-mooneyboth have advantages in a way just personal prefrenece really21:29
fungii'm with you on that, but to each their own21:30
fungifor better or for worse, github and its related workflows have dominated open source development mindshare in recent years, so anything which deviates from that is considered cumbersome or hard to understand21:32
corvusi force-push updates to PRs when asked to make changes in review.  no one has yelled at me yet.21:42
clarkbthe downside to that is github doesn't retain the old commits21:42
clarkbthey do keep the old comments and diff contexts now though21:42
clarkbprior to that change some people would complain if you force pushed over as a lot of review context would be lost21:43
sean-k-mooneyya but that a failing of github not really your use of it21:46
*** vorotech has quit IRC21:50
*** vorotech has joined #zuul21:54
*** vorotech has quit IRC21:55
*** rfolco has quit IRC22:14
openstackgerritBrian Haley proposed zuul/zuul-jobs master: Decrease MTU to account for IPv6 header  https://review.opendev.org/76180022:35
avasstobiash: re 747865, does changing job definition for a parent job cause a child job to run?22:55
avasslooks like most of the other jobs doesn't specify it's parent in files:22:55
corvusavass: supposed to (basically it's based on the serialization of the job)22:56
avassokay good to know22:56
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add nimble roles and job  https://review.opendev.org/74786522:57
clarkbI've just noticed that we didn't run a docker image promote in opendev land because we didn't match file matchers on the chagne that updated the image. The chagne that updated the image did so by updating the job parameters for the image builds. Is there a way of expressing "please always run this job in pipeline foo if a job in pipeline bar ran" ?22:59
clarkbin this case I think not because it also depends on the merge events? but it would be nice to be able to drop the fiel matchers from the promote job and trigger it via "the image build succeeded and the change landed" somehow22:59
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Remove unecessary files attributes from child jobs  https://review.opendev.org/76180223:00
corvusclarkb: i'm wondering if we should consider "lots of disparate images in one repo" an anti-pattern for reasons like this23:01
corvusclarkb: that's just a thought.  i don't have an immediate solution to the problem you pose.23:01
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Remove unecessary files attributes from child jobs  https://review.opendev.org/76180223:02
avasscorvus: how about we clean that up a bit? ^23:02
clarkbya its also not critical for us in opendev right now. Mostly bringing it up as a thing that would be good to address if possible23:02
clarkbIt was for intermediate images in a gerrit upgrade path that we'll never really use in production. The updates were minor too23:02
corvusclarkb: it may theoretically be possible; something like a soft dependency on an artifact.23:02
corvus(since the image-upload job produces an artifact)23:03
clarkbcorvus: oh ya we can still trigger on the merge action but then run jobs based on artifact prsence?23:03
corvusclarkb: well, yes, but to be clear: i was suggesting a zuul enhancement to allow you to essentially have a file matcher for artifacts.  but having said that, today you could probably do a zero-node job to check if the artifact exists and use that to decide whether to run a child job that does the promote.23:04
*** hamalq has joined #zuul23:05
corvus(the data and queries are all there to do that -- they're used to find dependent images for provides/requires)23:06
clarkbinteresting. If I ever find time I may try implementing that23:06
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add option to install kubernetes with kind  https://review.opendev.org/74093523:06
avassanyone wanna approve: https://review.opendev.org/#/c/760691/ so zbr can work on 208 easier without the warnings piling up faster than anyone can fix them?23:09
clarkbavass: did the new release to address my concern happen?23:10
corvusshould that pin to 4.3.7?23:10
corvus(since that addresses a concern from ianw)23:11
clarkboh ya I think if that is the change that fixes is the archive concern then ya23:11
clarkband it also addresses ianw's concern23:11
clarkb++ to that then I think we can land it23:11
avasssure I'll update it23:12
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: DNM: Add unified synchronize-repos role that works with linux and windows  https://review.opendev.org/74000523:12
avasstobiash: squashed ^ with the change I had on top of it23:12
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Enable progressive mode with ansible-lint  https://review.opendev.org/76069123:14
openstackgerritAlbin Vass proposed zuul/zuul master: install-js-tools: add support for manjaro  https://review.opendev.org/76180323:19
corvustil manjaro is an arch derivative.  avass are you using that?23:37
fungii've got a good friend who uses manjaro too, or at least did until recently23:40
avassyup23:41
* avass am using arch btw23:42
fungiahh, yeah, friend said he switched to ubuntu a couple weeks back after years on manjaro (decided it was too much fiddly maintenance)23:42
avass:)23:42
avassmanjaro is way less fiddly maintanence compared to arch though23:42
fungii'm not one to talk, i run a mix of debian/unstable and openbsd/current23:43
fungii probably suffer from some computing-oriented form of masochism23:45
avassoh you should try out windows then23:45
clarkbhahaha23:46
funginiiiice23:47
openstackgerritMerged zuul/zuul-jobs master: Enable progressive mode with ansible-lint  https://review.opendev.org/76069123:49
avassis it just me or is review.opendev.org behaving strange?23:51
fungican you qualify "strange"?23:52
avass that ^ change got merged but it doesn't show up as merged, or has any reviews. gonna check with a different computer23:53
clarkbI don't see that23:53
fungii see it merged with reviews23:53
clarkbcould be an issue between client and server caused that request for data to fail?23:54
fungiload average on review.o.o isn't low right now, but isn't heavy either23:54
fungiload average under 3 on a 16-way smp server23:55
avasslooks like it's just this computer for some reason23:55
corvustime for a new computer23:56
avassalso cannot download changes :(23:56
fungisuddenly broken ipv6 on that machine maybe?23:56
corvusavass: or maybe your computer is telling you it's friday evening :)23:56
avassI bought it today heh :)23:56
corvusavass: it should be in the return window!  "This computer is broken! It doesn't download changes!"23:57

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!