Monday, 2020-03-30

*** dangtrinhnt has joined #zuul00:41
*** armstrongs has joined #zuul00:56
*** swest has quit IRC01:37
*** Goneri has quit IRC01:48
*** rfolco has quit IRC01:48
*** swest has joined #zuul01:52
*** dangtrinhnt has quit IRC01:55
*** dangtrinhnt has joined #zuul01:56
*** dangtrinhnt has quit IRC01:57
*** dangtrinhnt has joined #zuul02:04
*** dangtrinhnt has quit IRC02:07
*** dangtrinhnt_ has joined #zuul02:07
openstackgerritIan Wienand proposed zuul/zuul-jobs master: test-upload-logs-swift: revert download script  https://review.opendev.org/71575502:11
openstackgerritIan Wienand proposed zuul/zuul-jobs master: bulk-download : role with script to download all log files  https://review.opendev.org/71575602:11
*** bhavikdbavishi has joined #zuul03:25
*** bhavikdbavishi1 has joined #zuul03:30
*** bhavikdbavishi has quit IRC03:31
*** bhavikdbavishi1 is now known as bhavikdbavishi03:31
*** dangtrinhnt_ has quit IRC03:37
*** dangtrinhnt has joined #zuul03:50
*** evrardjp has quit IRC04:03
*** dangtrinhnt has quit IRC04:08
*** evrardjp has joined #zuul04:10
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575604:13
*** dangtrinhnt has joined #zuul04:24
openstackgerritIan Wienand proposed zuul/zuul-sphinx master: Ignore __pycache__ directory when looking at roles  https://review.opendev.org/71576404:31
*** evrardjp has quit IRC04:36
*** evrardjp has joined #zuul04:36
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575604:44
*** saneax has joined #zuul04:44
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575604:51
*** dangtrinhnt has quit IRC04:58
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575605:00
*** bhavikdbavishi has quit IRC05:06
*** swest has quit IRC05:12
*** swest has joined #zuul05:13
*** bhavikdbavishi has joined #zuul05:22
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575605:31
AJaegermnaser: the problem was openstack-zuul-jobs, so test that one as well, please05:36
*** bhavikdbavishi has quit IRC05:44
*** bhavikdbavishi has joined #zuul05:45
openstackgerritIan Wienand proposed zuul/zuul-jobs master: local-log-download : role with script to download all log files  https://review.opendev.org/71575605:49
*** bhavikdbavishi1 has joined #zuul05:56
*** bhavikdbavishi has quit IRC05:57
*** bhavikdbavishi1 is now known as bhavikdbavishi05:57
*** bhavikdbavishi has quit IRC06:01
*** bhavikdbavishi has joined #zuul06:02
*** dpawlik has joined #zuul06:23
*** bhavikdbavishi has quit IRC06:31
*** bhavikdbavishi has joined #zuul06:32
*** bhavikdbavishi1 has joined #zuul06:37
*** bhavikdbavishi has quit IRC06:39
*** bhavikdbavishi1 is now known as bhavikdbavishi06:39
*** bhavikdbavishi has quit IRC06:51
*** bhavikdbavishi has joined #zuul06:52
*** jcapitao has joined #zuul07:17
*** tosky has joined #zuul07:25
*** ysandeep|rover is now known as ysandeep|rover|l07:25
*** jcapitao has quit IRC07:29
*** jcapitao has joined #zuul07:31
*** bhavikdbavishi1 has joined #zuul07:34
*** arxcruz|off is now known as arxcruz07:35
*** bhavikdbavishi has quit IRC07:35
*** bhavikdbavishi1 is now known as bhavikdbavishi07:35
*** armstrongs has quit IRC07:39
*** avass has joined #zuul07:41
tobiashinfra-root: when was your last scheduler restart? We've been hit by a significant memleak after our last update on friday (oom within less than a day).07:45
tobiashlooks like opendev is not (yet) affected and I'd like to strip down the patches that might have introduced this07:46
*** rishabhhpe has joined #zuul07:49
*** jpena|off is now known as jpena07:53
*** bhavikdbavishi has quit IRC08:08
tobiashright now I suspect https://review.opendev.org/714852 as the source as this is the only real thing we introduced on friday to our zuul08:28
*** bhavikdbavishi has joined #zuul08:30
*** harrymichal has joined #zuul08:33
*** bhavikdbavishi has quit IRC08:34
*** ysandeep|rover|l is now known as ysandeep|rover08:34
*** bhavikdbavishi has joined #zuul08:36
*** harrymichal has quit IRC08:57
*** rishabhhpe has quit IRC09:13
*** rishabhhpe has joined #zuul09:16
rishabhhpeHello All , Facing issue while fetching and cherry-picking the clone from cinder repo for stable/train release branch .. is there any one else facing the same issue .. i can see last check in done two days back .. and my CI is also failing with same issue from past two days only09:20
*** rishabhhpe has quit IRC09:25
*** rishabhhpe has joined #zuul09:25
AJaegertobiash: I think we log this via status log, let me check...09:26
tobiashAJaeger: thanks, I think I found the reason (not yet merged change above)09:27
AJaegertobiash: https://wiki.openstack.org/wiki/Infrastructure_Status has an entry on the 28th of February09:27
tobiashcool, thx09:28
AJaegerrishabhhpe: you asked on #openstack-qa and I think you got the answer there: If you have local content in your checkout copy, it would explain the problem. So, get rid of that09:30
rishabhhpeAjaeger: thats a fresh VM and it is taking all the stuff while installing the devstack apart from that none other checking i am doing in that repo .. also when same code i am checking out from u release and doing the same no error is coming09:32
rishabhhpeso it seems some wrong check in done for train release .. which is causing the problem .. that is why i posted the same here with new reframed sentence .. so that other can also comment if they are facing the same problem09:33
*** sgw has quit IRC09:39
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Allow configure-mirrors to enable extra repos  https://review.opendev.org/69388709:40
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Allow configure-mirrors to enable extra repos  https://review.opendev.org/69388709:41
*** harrymichal has joined #zuul09:43
AJaegerrishabhhpe: Please try reproducing this on a clean tree locally09:45
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Improve job and node information banner  https://review.opendev.org/67797109:47
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Avoid confusing rsync errors when source folders are missing  https://review.opendev.org/67004409:52
*** bhavikdbavishi has quit IRC09:53
*** bhavikdbavishi has joined #zuul09:53
zbrmorning everyone! i wonder if i can get some help with some (simple) reviews, the pile is growing and I already had to drop valid ones10:01
zbrlike https://review.opendev.org/#/c/703425/10:01
openstackgerritSorin Sbarnea proposed zuul/zuul master: For pre blocks to wrap text  https://review.opendev.org/68153210:08
*** dmellado has quit IRC10:50
*** jcapitao is now known as jcapitao_lunch11:02
*** rfolco has joined #zuul11:24
*** jpena is now known as jpena|lunch11:34
*** ysandeep|rover is now known as ysandeep|rover|b11:51
*** rlandy has joined #zuul12:01
*** dmellado has joined #zuul12:06
*** rishabhhpe has quit IRC12:09
*** ysandeep|rover|b is now known as ysandeep|rover12:13
mnaserAJaeger: https://review.opendev.org/715928 :)12:14
AJaegermnaser: thanks! I suggest to make it fail, so that we see the reporting as well ;) But let's try first without failure.12:18
*** jcapitao_lunch is now known as jcapitao12:24
*** jpena|lunch is now known as jpena12:30
mnaserAJaeger: i got a failure in openstacksdk, but sure, i can make a failure case in there too12:31
AJaegermnaser: then we're good12:32
mnaserAJaeger: you can checkout the topic i used for the change :)12:33
AJaegermnaser: will do later, thanks12:33
mordredmnaser: the sdk patch is so cool12:35
jkthow do I run zuul's own test suite? I started by creating a venv, then running `pip install -e .`, and then `tox -l`, but tox fails with "ERROR: unknown environment 'py3-docker'"12:55
jktso I tried `pip install docker`, but that doesn't appear to help12:55
jktdo I need docker locally?12:55
jktah, well, here's TESTING.rst, never mind12:55
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded  https://review.opendev.org/69005713:03
*** harrymichal has quit IRC13:05
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: install-docker: allow removal of conflicting packages  https://review.opendev.org/70230413:05
*** irclogbot_1 has quit IRC13:13
mordredzbr: in that install-docker patch - docker.io is the debuntu package name - could you add that to the defaults for those?13:15
*** guilhermesp has quit IRC13:15
*** jtanner has quit IRC13:15
*** gundalow has quit IRC13:15
*** rlandy has quit IRC13:15
*** rlandy has joined #zuul13:16
*** jtanner has joined #zuul13:16
fungitobiash: `stat /var/run/zuul/scheduler.pid` says 2020-03-03 15:24:04.48720757213:19
*** irclogbot_1 has joined #zuul13:19
fungidoesn't appear we logged the git commit id for that restart at https://wiki.openstack.org/wiki/Infrastructure_Status13:21
tobiashfungi: thanks, on deeper look I saw that we did only incluse the node leak mentioned above into our deployment so that seems to be the source of the memleak (I now also can spot that in the change, but cannot explain why that's leaking 1gb/2h in our deployment)13:21
fungiit's worth noting that our status log there indicates we restarted the scheduler on 2020-02-27 due to "memory pressure"13:23
tobiashI've commented on https://review.opendev.org/714852 with the suspected source of the memleak13:23
tobiashit's like inception, a node leak fix introduces a mem leak...13:24
fungitobiash: okay, so you've had 714852 applied in production, the leak may not be on master yet?13:33
zbrmordred: sure, let me look again at it.13:33
*** bhavikdbavishi has quit IRC13:35
mordredtobiash: I agree - that patch does seem likely - but also, 1gb/2h seems like a large leak13:35
tobiashfungi: correct, it's not merged yet13:36
fungithanks for confirming13:36
*** Goneri has joined #zuul13:40
*** harrymichal has joined #zuul13:41
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: install-docker: allow removal of conflicting packages  https://review.opendev.org/70230413:45
*** bhavikdbavishi has joined #zuul13:50
*** lseki has joined #zuul13:57
*** sgw has joined #zuul13:57
*** dmellado has quit IRC14:04
*** bhavikdbavishi has quit IRC14:05
*** dmellado has joined #zuul14:05
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Adds roles to install and run hashicorp packer  https://review.opendev.org/70929214:11
*** Goneri has quit IRC14:11
*** ysandeep|rover is now known as ysandeep|away14:12
*** Goneri has joined #zuul14:14
AJaegermnaser: looks great!14:21
AJaegerteam, do we want to merge https://review.opendev.org/#/c/715727/ again? That's the pep8 inline comments feature.14:22
tobiashmordred: hrm, I wonder if the node-request references the buildset or layout, that would explain such a large leak14:30
mordredtobiash: oh yeah14:31
tobiashmordred: my theory is currently imploding :/14:35
mordredoh no14:35
tobiashaccording to https://opendev.org/zuul/zuul/src/branch/master/zuul/nodepool.py#L74 the leaked node requests would be reported in the stats14:35
tobiashwhich is not the case14:35
mordredtobiash: I agree. if your theory was solid, you should see that rising14:36
*** avass has quit IRC14:36
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Allow configure-mirrors to enable extra repos  https://review.opendev.org/69388714:37
tobiashmordred: it crashed on friday with a queue of 4214:38
mordredugh :(14:38
mordredzbr: there's actually a spec about improvements to the mirror construct - let me see if I can find it14:40
fungimordred: it's basically in the zuul docw14:40
fungidocs14:40
*** rishabhhpe has joined #zuul14:40
corvusmordred, fungi, zbr: https://zuul-ci.org/docs/zuul-jobs/mirror.html14:40
corvusmordred, fungi, zbr: a change working on implementing it for os mirrors: https://review.opendev.org/67757814:41
fungier, yeah, zuul-docs. just found it14:41
mordredcorvus: thanks! that's what I was looking for :)14:41
fungigah, zuul-jobs docs i mean14:41
zbrfungi: mordred: the linked change is 6mo old, and very red.14:50
mordredyup. it still needs work14:50
mordredbut the overall design has been agreed to across the zuul folks - so it's just a matter of pushing the implementation forward. doing so would greatly benefit everybody14:51
zbri would say a minor fix today is much better that a big refactoring that never ships :D14:51
mordredwell, refactorings never ship if we only ever work on minor fixes today ;)14:52
tobiashmordred: at least the requests do have a ref to the buildset14:52
tobiashso maybe a few leaked requests are already enough to leak a lot14:52
mordredtobiash: yeah14:52
*** bhavikdbavishi has joined #zuul14:55
tobiashat least yappy tells me that there are around twice as many tenant objects in memory than there are configured tenants15:00
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: install-docker: allow removal of conflicting packages  https://review.opendev.org/70230415:00
*** bhavikdbavishi has quit IRC15:01
*** yoctozepto has quit IRC15:07
*** yoctozepto has joined #zuul15:08
*** toabctl has quit IRC15:08
zbrcorvus: i do not think is ok to prevent changes today just because 6mo ago there was an attempt to rewrite a role, clearly if nobody touched in 6mo is very unlikely that it will be addressed in the next weeks.15:08
zbri am not against the rewrite, but looking for more pragmatic approaches, like what can we deliver in resonable amount of time15:09
*** Miouge has quit IRC15:09
*** arxcruz has quit IRC15:09
*** EmilienM has quit IRC15:10
*** arxcruz has joined #zuul15:10
*** Miouge has joined #zuul15:11
fungizbr: nobody has touched it in that timespan because what we have now is working reasonably well, but reviewing new changes to it is a pain and will only get worse as we continue to tack more things onto it. consider this as like what teams in openstack complain about when vendors just want to cram their new features into the software and not help with generalized improvements15:11
*** EmilienM has joined #zuul15:11
zbrwhich are these "generalized improvements"? asking because afaik, just ubuntu is tested on all roles, all the other platforms have partial coverage.15:13
zbrfungi: to be clear, that open particular change is not very important15:18
zbri still have a long list of of generalized improvements, like https://review.opendev.org/#/c/690057/ -- is this ok?15:20
fungigeneralized improvements meaning a logical framework to handle communicating mirror/proxy resources for zuul environments in a consistent manner, rather than what we have now which is basically just a forklift of what congealed in opendev over the years15:20
zbrthat is really a hard goal15:22
fungiwe've met harder goals in the past15:24
fungimost of the challenge is coming up with a schema/protocol for encoding mirror details. the implementation flows from that15:28
*** dmellado has quit IRC15:32
*** rishabhhpe has quit IRC15:33
zbrhow about https://review.opendev.org/#/c/706262 ?15:37
*** andreykurilin has quit IRC15:39
*** dmellado has joined #zuul15:39
fungizbr: how about it in what sense? that doesn't seem related to mirror configuration15:44
*** tdasilva has quit IRC15:45
*** evgenyl has quit IRC15:45
*** donnyd has quit IRC15:45
*** Shrews has quit IRC15:45
*** stevthedev has quit IRC15:45
*** tributarian has quit IRC15:45
*** ttx has quit IRC15:45
*** masterpe has quit IRC15:45
*** tdasilva has joined #zuul15:45
*** evgenyl has joined #zuul15:45
*** donnyd has joined #zuul15:45
*** Shrews has joined #zuul15:45
*** stevthedev has joined #zuul15:45
*** tributarian has joined #zuul15:45
*** ttx has joined #zuul15:45
*** masterpe has joined #zuul15:45
*** andreykurilin has joined #zuul15:46
*** masterpe has quit IRC15:48
*** hashar has joined #zuul15:51
zbrfungi: they are unrelated. amount mirrors, I got the message. if suppose that if I can find some time I may rework the refactoring patch in the future.15:57
zbrfungi: i tried to find some references regarding filenames put under sudoers.d/ directory but I was not able to find anything concrete.16:11
zbrmy impression was that others used "usernames" not service names (likely the same), but i have no proof.16:12
zbrclearly documentation does not make any recomandation16:12
fungiyeah, i'm mostly curious, do you know why it would be assumed that /etc/sudoers.d/zuul would only contain authorization for a user account named "zuul" (or for that matter, that it would make sense for the file in that directory to be named the same as whatever username ansible uses)?16:12
fungisudo doesn't actually care what the file is named16:13
fungiit's an arbitrary filename16:13
fungimakes me wonder if what people really want is for that filename to be configurable via a variable16:14
fungirather than tying the filename unnaturally to the username16:14
zbri am inclined to believe it makes a little bit more sense to use usernames, mainly because you can run multiple copies of the same service16:14
clarkbI would use a filename that ties it back to the source16:15
zbrin the end the file is expected to set priviledges for the user not for the service16:15
clarkbzuul-jobs-manage-sudo or whatever16:15
fungi690057 would be encoding the expectation that whatever username ansible is authenticating with, there will be a file under /etc/sudoers.d with the same name16:15
clarkbit doesn't need to be configurable as long as we avoid collisions (and tieing it to the source is a good way of doing that)16:15
fungiif ansible logs in with a username of "admin" or "ubuntu" or whatever, you can put a line for that in /etc/sudoers.d/zuul (or multiple entries if you like, or authorize %groups instead of usernames in it, even)16:16
fungiclarkb: yeah, i'm trying to understand the actual concern. if the concern is that people want the filename to be something other than zuul then that could be made configurable i suppose16:18
clarkbfungi: I'm also not sure such a concern is valid?16:18
clarkbit says zuul in the name because it originated from zuul16:18
clarkbthat is a good thing :)16:18
fungiright, it's the only explanation i can come up with for people wanting that file to not be named "zuul"16:18
zbrTBH, i would not have cared about that change if I was not suggested to rebased another on on it. I guess that some zuul deployments do create a sudoers file that is using a custom username filename instead of the service name.16:23
corvustobiash: yes, i think the noderequest does have a path to the layout: NodeRequest -> BuildSet -> Item -> Layout  [also Item -> Pipeline -> Tenant]16:27
clarkbzbr: fungi ah is the use case to clean up an existing file?16:28
clarkbI could see making the cleanup side configurable if that is the use case16:28
tobiashcorvus: yeah, found it and it explains the severity of the leak16:28
tobiashjust did a restart 90 minutes ago and the revert seems to flatten the curve16:29
corvustobiash: cool, i left 2 comments on the change.  the question about the alternate approach is mostly just exploration; i'm not suggesting that's a good idea, just sounds worth looking into16:30
zbrclarkb: based on who raised the CR, i expect Volvo uses a custom setup. I wonder if tristanC can give some insights regarding rdo/sf usage.16:30
zbrif we have more than one deployment that assumed that that correct location is sudoers.d/$username instead of sudoers.d/$service maybe it make sense to do it.16:31
tobiashcorvus: thanks, responded16:32
tobiashI'll think I'll try that as your suggestion seems to be more memleak proof for the future16:32
tobiashespecially given that if we have a memleak there it's quite severe16:33
tobiashyour suggestion would also not require test code changes as well16:35
*** evrardjp has quit IRC16:36
*** evrardjp has joined #zuul16:36
*** jcapitao has quit IRC16:40
corvusmordred, tobiash: i'm worried i'm getting confused on https://review.opendev.org/714508 can you double check my comment? :)16:44
*** masterpe has joined #zuul16:47
mordredcorvus: you're right - we're missing a not. will update in just a minute16:47
tobiashcorvus: you're totally right16:48
tobiashthat's why we require two reviews :)16:48
*** avass has joined #zuul16:50
*** zxiiro has joined #zuul17:09
*** jpena is now known as jpena|off17:22
*** bhavikdbavishi has joined #zuul17:42
*** bhavikdbavishi1 has joined #zuul17:44
*** bhavikdbavishi has quit IRC17:46
*** bhavikdbavishi1 is now known as bhavikdbavishi17:46
mnaseri know this might not be the best place, but  know there's quite a few gertty users in here18:03
mnaseris there a shortcut of a "go to change by id" ?18:03
fungictrl-o is the default keybinding for a gerrit search18:04
fungiif you just stick the change number in there, you'll be taken to it18:05
mnaserlet me try that18:05
fungithere is also a cli command for that18:05
fungi`gertty --open ...` from a shell will instruct the already running gertty process to open that18:06
fungiso you could for example have your browser call that on specific urls18:06
mnaserhmm, ctrl-o seems unresponsive, but i wonder if that's just because tmux is capturing that (or not sending it)18:06
fungi(though i think to use --open you may have to phrase your change identifier in the form of a url)18:07
fungithe ? key should give you interactive, context-sensitive help18:08
fungiunder Global Keys my help screen says "CTRL-o Search for changes"18:08
fungimaybe you've remapped it18:08
mnaserhmm, ctrl+r works (i see the sync number going up), but ctrl+o does not do anything (and i did not remap it, and the contextual help shows it is still ctrl+o)18:08
fungior yeah, maybe your terminal or something is eating ctrl-o, in which case you could rebind it in your .gertty.yaml18:08
mnasereven ctrl+q works too, so it must be something with ctrl+o18:09
mnaserhttps://apple.stackexchange.com/a/325518:10
mnaser"⌃+O is, for some reason (probably having to do with it being used for flow control on some kinds of serial connections) set to be discarded by the terminal driver (i.e. not Terminal.app, but the part of the OS between it and the shell). You can get rid of this with the command stty discard undef. To make this change permanent, add this command to your .bash_profile and .bashrc files."18:10
fungineat!18:11
fungiftr, xorg->xterm->bash->mosh->tmux->gertty is handling ctrl-o just fine for me18:12
fungii guess that's really xorg->ratpoison->xterm->bash->mosh->tmux->bash->gertty18:12
openstackgerritMerged zuul/zuul-jobs master: test-upload-logs-swift: revert download script  https://review.opendev.org/71575518:14
mnaserfungi: that did the trick18:18
mnaserfungi: next on my list is figuring out how to make clicking those in weechat launch in gertty, but that's for another time18:18
avassregarding: https://review.opendev.org/#/c/706262/18:18
avassI couldn't remember why we wanted this and I've been looking around and I can't actually find a usecase for it on our end18:19
fungimnaser: yeah, and that's what you're going to want to use `gertty --open ...` for18:21
*** rlandy is now known as rlandy|brb18:29
avassBut I'll have to make sure with some other teams so I'm not just missing something18:29
fungiavass: cool, i'm not adamantly opposed to the idea, just would want to be sure we understand the use case because there might be better options to address it18:32
fungihaving a role magically change its behavior depending on the username seems likely to lead to more confusion18:33
avassfungi: it could be that we had some strange setup somewhere that has been removed since we're always changing so many things18:41
avassfungi: to be honest, it would make more sense to have that file configurable, preferably in nodepool somehow since in aws we're using the 90-cloud-init-users file18:42
*** y2kenny has joined #zuul18:43
*** bhavikdbavishi has quit IRC18:48
corvusmnaser: https://opendev.org/ttygroup/gertty#user-content-macos  and  https://opendev.org/ttygroup/gertty#user-content-terminal-integration  may be useful18:52
mnasercorvus: oh maybe i can update the docs to provide an alternative18:53
*** rlandy|brb is now known as rlandy18:54
corvusmnaser: thanks!18:55
y2kennySince namespace and pod created by the k8s driver is ephemeral, is there a recommended way to share persistent resources (something like a build cache or repo cache?)18:58
*** y2kenny28 has joined #zuul19:02
*** y2kenny28 has left #zuul19:02
*** y2kenny has quit IRC19:03
*** y2kenny has joined #zuul19:05
fungiy2kenny: what we do is have jobs which prebuild artifacts like that and then configure them as variables which our jobs can refer to19:08
y2kennydo you mean you pass in the prebuild artifacts via the executor?19:09
fungihost the prebuilt artifacts somewhere reachable from the job nodes19:09
openstackgerritMonty Taylor proposed zuul/zuul master: Strip by default in tools/encrypt_secret  https://review.opendev.org/71450819:10
mordredcorvus, tobiash: I think that got it right now? ^^19:10
fungiy2kenny: an example in opendev's deployment is python wheels, because we deal with a lot of python-based projects. normally when you install a source distribution package for a python module the package management tooling performs just-in-time compilation of that package into a binary "wheel"19:10
fungiy2kenny: so we have jobs which periodically build those for all our test platforms and then add them to a central repository reachable from the job nodes19:11
y2kennyfungi: um... I suppose this is not using k8s or openshift objects?  I am wondering because there is really no way to share stuff like persistence volume since things are in different namespaces19:12
fungiy2kenny: right, we use publication channels19:12
fungihave the executor fetch the artifacts from the build nodes and write them into a central repository (an afs volume in this case)19:13
fungiand then we front that afs volume with a webserver and the build nodes can fetch prebuilt things from it over https19:14
y2kennyfungi: ok... I will need to rethink the architecture a bit.19:15
fungiin the general case of stuff like ccache, i don't know how you'd go about having untrusted jobs contribute to a build cache, taking problems like write credentials and cache poisoning into account19:15
fungiit would definitely be an interesting space to explore though19:15
mordredthat might be less of a concern in a more trusted environment19:16
y2kennyyea... I haven't got to that level of security at this point.19:16
mordredbut ccache operates as a network service - so if environmentally it was ok to use a shared one amongst the users, you coudl imagine plumbing the config env vars through19:17
mordredwe dont' have good examples of that from opendev - becuase of the public nature :)19:17
fungiright, in which case you'd maybe just fetch the cache from each job node during log collection and have the executor merge them into some central cache which the job nodes know to pull from (or which you have an early role in pre sync a copy of onto the job node)19:17
mordredfungi: right - but I mean - ccache does that by itself without needing to sync19:17
fungior even embed your ccache credentials on the job nodes if that's safe for you19:17
mordredassuming it's a thing that's ok to use based on mutual trust19:17
mordredyeah19:18
fungiright, maybe put a ccache server somewhere your job nodes have a route to in that case, and just configure your jobs to know the dns name or address of the ccache server you want them to all push into and pull from?19:19
fungithe solution will likely depend a lot on the exact nature of the data you want to cache and your risk model for builds19:20
mordredyeah19:20
mordredwe pondered (briefly so far) a similar thing related to the bazel build farm service google runs when thinking about builds in gerrit's new zuul19:21
mordredI don't have a solution yet - because it's a bit complex in that case due to the public nature again19:21
fungias mordred notes, most of the standard library in zuul was built with the idea that you may be running an entirely publicly accessible zuul deployment which takes untrusted changes from anyone on the internet and runs jobs against that, so is constrained by the requisite levels of paranoia19:21
y2kennyright.  more thinking for me to do.  I will probably go without cache for now and optimize for performance later.19:21
mordredyeah. it means you can be sure it's all paranoid for security ... but might be overkill in some more trusted envs19:22
mordredy2kenny: ++19:22
mordredI'm a fan of correctness first, optimize second :)19:22
y2kennyit's good that you guys are thinking about the security stuff from the start.  I don't think these type of things can be bolted on later.19:22
y2kennybut it does adds to the learning curve.  I am just reading up on the job secret stuff right now.  Need to convince myself storing encrypted secrets in git is ok.19:24
y2kenny(I am sure it is... but putting things in git just feel so... forever :))19:25
*** saneax has quit IRC19:27
fungicredentials are only forever if you can't revoke/replace them! ;)19:37
fungiin my opinion, if you have credentials which are irreplaceable/irrevokeable, then you should probably not put them in git (or use them at all really)19:38
fungii'm honestly more concerned about leaking plaintext secrets in job logs than someone working out how to decrypt an asymmetrically-encrypted secret in a git repository19:41
y2kennyfungi: make sense.  (My credentials are definitely revocable)19:50
*** mugsie has quit IRC19:51
*** harrymichal has quit IRC19:52
*** mugsie has joined #zuul19:54
fungibut yeah, if there's anything i've learned from my many years focusing on information security, it's that you need to plan for when, not if, you lose control of your secrets, and design your policies and processes to limit the impact of those incidents, rather than having highly-guarded secrets and getting by on the hope that they're never leaked19:57
*** dpawlik has quit IRC19:59
*** sshnaidm is now known as sshnaidm|afk20:07
*** dpawlik has joined #zuul20:08
*** dpawlik has quit IRC20:13
y2kennydoes the addition of secrets make a pre-review job into a post-review job?20:42
y2kenny(got an "unable to freeze job graph" after I associated a secret to a job...)20:44
fungiy2kenny: no, basically you can't include a secret in a job which is being run in a pre-review pipeline, nor can you add a job with secrets to a pre-review pipeline20:45
y2kennyo... what is the reason behind that?20:47
fungibecause an untrusted change could `echo $secret` in the console log, while code reviewers are expected to keep an eye out for such shenanigans20:47
y2kennyoh right... of course....20:48
fungibut if you don't have that risk, you could just set all your pipelines as "post-review"20:48
y2kennysilly me :)20:49
*** hashar has quit IRC20:49
y2kennyI will do that for now only because I am still experimenting20:49
fungias you pointed out, we do try to design for such situations20:49
y2kennyI am trying to figure out how to pass secrets into k8s for image creation20:50
y2kennyand I hope to do the trying in pre-review without submiting the experimental patches20:50
fungiright, ultimately you would probably do that in a pipeline triggered periodically off an already merged repository state, or in a pipeline where approved changes go to be merged20:51
fungior possibly triggered from events of the branches getting updated when changes merge, or something along those lines20:51
fungizuul's security model assumes the people approving changes for a repository are already trusted with access to secrets stored in that repository20:52
y2kennyunderstood.20:52
corvusy2kenny: here's a job that uses secrets to deploy an app (zuul itself) to k8s: https://gerrit.googlesource.com/zuul/ops/+/refs/heads/master/.zuul.yaml20:52
y2kennycorvus: great, thanks!20:53
corvusy2kenny: that's in a config-project repo, so the entire repo is trusted and never speculative; you'll note there's no pre-review check job (but there could and should be -- we have the ability to spin up a k8s and perform a test deployment; it's just new and ENOTIME)20:53
*** tjgresha_ has quit IRC20:57
openstackgerritJames E. Blair proposed zuul/nodepool master: Add ZooKeeper TLS support  https://review.opendev.org/71273320:59
openstackgerritMerged zuul/zuul-jobs master: Improve job and node information banner  https://review.opendev.org/67797121:37
*** y2kenny has left #zuul22:00
*** tosky has quit IRC22:20
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: zuul-restart: change service order to prevent tenant loading failure  https://review.opendev.org/71542422:28
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Set default secret mode to 0400  https://review.opendev.org/71450122:29
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add integration test playbook  https://review.opendev.org/71416522:30
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add nodepool launcher service initial deployment  https://review.opendev.org/71531022:31
tristanCcorvus: mnaser: it seems like i found a simple solution with 715424 to fix automatic zuul restart issues.22:42
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add nodepool external config  https://review.opendev.org/71531122:50
openstackgerritIan Wienand proposed zuul/nodepool master: Update dib dep to 2.35.0  https://review.opendev.org/71610422:50
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Adapt the integration playbook to be usable locally  https://review.opendev.org/71416322:53
*** saneax has joined #zuul22:53
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add nodepool labels to integration test  https://review.opendev.org/71531622:53
*** rfolco has quit IRC22:57
*** rfolco has joined #zuul22:58
*** rfolco has quit IRC22:59
clarkbthere is a question about why we use merge if necessary and not rebase if necessary (or cherry pick) with zuul and gerrit on the mailing list23:08
clarkbI would respond but my memory is really fuzzy on this. I think it comes down to gerrit rewrites your commit messages and not just the commits themsevles when it does that and it creates problems?23:08
mordredclarkb: it's dev confustion23:10
fungiheh, i was about to say the same thing ;)23:10
mordredwant me to answer?23:10
clarkbmordred: ya I think someone that has a clearer memory should respond23:11
mordredwhich ML?23:11
fungithe commit id (git sha) in your local copy may never appear in gerrit's repo because of it rewriting the commit to rebase or cherry-pick23:11
fungimordred: zuul-discuss23:12
mordredahh23:12
fungithough a more modern reason to avoid those is that it's not compatible with signed commits23:13
fungigerrit can't recreate your signing key/signature23:13
fungiso you may push a change with a signed commit, but gerrit rebases or cherry-picks that and recreates the commit with no signature23:14
fungibecause it has no other option23:14
fungialso there's the point that if you really don't want to see a bunch of messy merge commits in your git log, it's just a --no-merges away23:15
*** sanjayu_ has joined #zuul23:23
*** saneax has quit IRC23:26
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add nodepool kubernetes pod label to integration test  https://review.opendev.org/71531623:26
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add nodepool kubernetes pod label to integration test  https://review.opendev.org/71531623:28

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