Thursday, 2019-06-06

*** michael-beaver has quit IRC00:08
*** mattw4 has quit IRC00:15
*** mattw4 has joined #zuul00:15
jktbtw, I'm getting this error with updated zuul's zuul-jobs: http://paste.openstack.org/show/752558/00:23
jktthis is because zuul-jobs.git now assumes that it's called zuul/zuul-jobs everywhere, on all Zuul instances00:23
*** mattw4 has quit IRC00:24
jkton my system, it's called ci/zuul-jobs though00:24
SpamapSI've had a similar problem in the past with base jobs.00:26
SpamapSjkt: I think you may have to call it zuul/zuul-jobs. :-/00:26
jktcorvus: it seems that this warning (http://paste.openstack.org/show/752558/) on installations where zuul-jobs is not named zuul/zuul-jobs has been introduced in your commit 2f2d6ce300:27
jktSpamapS: if this is intentional, then I will be able to adapt, sure, but I think that this might have been just a mistake00:28
corvusjkt: we fixed that about 10 hours ago in https://opendev.org/zuul/zuul-jobs/commit/f1264e0f6071a11c5105fbc7edc71efc7e236fc300:29
corvusjkt: if it's still a problem, maybe a full reconfigure would get the update, or if not, maybe a scheduler restart00:30
jktcorvus: sorry for noise00:30
corvusjkt: sorry for the error00:30
*** sanjayu__ has quit IRC00:42
*** spsurya has joined #zuul01:01
*** jamesmcarthur has joined #zuul02:41
*** rlandy|ruck|bbl has quit IRC02:45
*** jamesmcarthur has quit IRC03:08
tristanCfungi: mhu: there is indeed something wrong with the test-job-tox-el7, it may be related to the host upgrade we did yesterday04:34
tristanCfungi: the funny name is generated by: https://softwarefactory-project.io/logs/56/663056/7/third-party-check/test-job-tox-f27/292d825/ara-report/file/85639583-d11d-4b3f-8cbd-77c9098e3d69/#line-1404:35
*** pcaruana has joined #zuul04:50
tristanCit's now fixed, there was an issue with the test playbook. Thanks for noticing!04:51
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: Return javascript content artifact records to Zuul  https://review.opendev.org/66305606:17
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: Return python artifact records to Zuul  https://review.opendev.org/66305306:19
*** raukadah is now known as chandankumar06:24
*** sanjayu__ has joined #zuul06:25
*** sanjayu_ has joined #zuul06:27
*** sanjayu__ has quit IRC06:29
openstackgerritMerged zuul/zuul-jobs master: Allow download-artifact to download multiple files  https://review.opendev.org/66287606:33
openstackgerritMerged zuul/zuul-jobs master: Return javascript content artifact records to Zuul  https://review.opendev.org/66305606:39
*** themroc has joined #zuul06:48
openstackgerritMerged zuul/zuul-jobs master: Return python artifact records to Zuul  https://review.opendev.org/66305306:57
*** gtema has joined #zuul06:58
*** weshay has quit IRC07:22
*** mhu has quit IRC07:22
*** mhu has joined #zuul07:22
*** weshay has joined #zuul07:23
*** ParsectiX has joined #zuul07:24
*** themroc has quit IRC07:26
*** jpena|off is now known as jpena07:38
*** hashar has joined #zuul07:46
*** sshnaidm|afk is now known as sshnaidm09:05
ofososThe documentation on zuul-ci.org says that native container workflows are not yet implemented yet, can I request containers with nodepool anyway and run my builds there?09:22
*** felixgcb has joined #zuul09:33
SpamapSofosos: there's a kubernetes driver, but I didn't have much luck with it.10:03
SpamapSI believe the openshift driver gets more testing.10:04
*** flepied has quit IRC10:22
*** ParsectiX has quit IRC10:32
*** ParsectiX has joined #zuul10:33
*** jpena is now known as jpena|away10:36
*** gtema_ has joined #zuul10:42
*** gtema has quit IRC10:42
*** ParsectiX has quit IRC10:48
*** ParsectiX has joined #zuul10:59
*** ParsectiX has quit IRC10:59
*** ParsectiX has joined #zuul11:06
*** flepied has joined #zuul11:18
*** ParsectiX has quit IRC11:26
*** rlandy has joined #zuul11:59
*** rlandy is now known as rlandy|ruck12:00
*** gtema_ has quit IRC12:05
*** felixgcb has quit IRC12:05
*** hashar has quit IRC12:13
*** gtema_ has joined #zuul12:27
*** pcaruana has quit IRC12:52
*** gtema_ has quit IRC13:32
*** jpena|away is now known as jpena13:53
*** jamesmcarthur has joined #zuul14:05
*** gtema_ has joined #zuul14:16
*** swest has quit IRC14:17
pabelangermorning! Looking for reviews on https://review.opendev.org/660856/ (from tristanC) to fix timer trigger file matching, and https://review.opendev.org/663378/ is fix use case with cisco network appliance.14:29
pabelangerthanks!14:29
*** hashar has joined #zuul14:33
*** sanjayu_ has quit IRC14:39
ShrewsSpamapS: if the kubernetes driver doesn't actually work, we should either poke the author for fixes, or remove it15:09
Shrewspreferably the former15:10
*** chandankumar is now known as raukadah15:10
SpamapSShrews: It has been on my todo to try it again for a while.15:11
SpamapSWhen I tried it, the nodepool driver worked fine, it was the Zuul side of it that didn't work right.15:11
SpamapSSomething with the tokens and auth15:12
ShrewstristanC: ^^15:12
*** hashar has quit IRC15:13
mordredSpamapS: wasn't that because you were using eks which uses a different auth mechanism than normal k8s and we didn't have an answer for how to deal with that?15:15
openstackgerritMerged zuul/zuul-jobs master: Explicitly store date facts for promote  https://review.opendev.org/66281715:29
*** AJaeger has quit IRC15:38
openstackgerritFabien Boucher proposed zuul/zuul master: A reporter for Elasticsearch  https://review.opendev.org/64492715:44
fungiyeah, we can automatically test the kubernetes driver since it's all free software we can just install... but eks on the other hand not so easy to do in our opendev ci15:45
openstackgerritFabien Boucher proposed zuul/zuul master: A reporter for Elasticsearch  https://review.opendev.org/64492715:46
*** tjgresha has joined #zuul16:25
SpamapSmordred:that was a hypothesis I had16:29
clarkbwith the js tooling fix https://review.opendev.org/#/c/662339/1 passes now and I think that is a worthwhile update to zuuls js testing as it removes a set of variables we were otherwise having to consider16:38
clarkbI rechecked the child change as well which I think need a bit more careful review but should also be considered16:38
clarkbfixes a js dep issue if it works16:38
*** mgoddard has quit IRC16:48
*** mgoddard has joined #zuul16:50
openstackgerritDavid Shrewsbury proposed zuul/zuul master: WIP: Add caching of autohold requests  https://review.opendev.org/66341216:58
*** mrhillsman is now known as openlab17:02
*** openlab is now known as codebauss17:05
*** codebauss is now known as openlab17:13
*** openlab is now known as codebauss17:14
*** codebauss is now known as openlab17:15
*** openlab is now known as codebauss17:16
openstackgerritDavid Shrewsbury proposed zuul/zuul master: Store autohold requests in zookeeper  https://review.opendev.org/66111417:19
openstackgerritDavid Shrewsbury proposed zuul/zuul master: WIP: Add caching of autohold requests  https://review.opendev.org/66341217:19
*** yolanda__ has joined #zuul17:20
*** mattw4 has joined #zuul17:22
*** yolanda has quit IRC17:23
*** jpena is now known as jpena|off17:23
*** codebauss is now known as mrhillsman17:24
*** jamesmcarthur has quit IRC17:33
SpamapSHas anyone looked in to "zuul pushes" of late? I'm having some awkward conversations about git hashes and it would be great if we didn't have to store Zuul build UUIDs in the binaries built in the gate.17:35
corvusSpamapS: not that i'm aware of but i believe it would still be welcome.17:37
fungiyeah, it's something i've been looking forward to having for opendev if someone gets time17:37
fungithere is a class of features which would be nice to have but hinge on zuul controlling the actual repository state and not delegating that control to the hosting system17:38
*** spsurya has quit IRC17:40
fungiand at the moment i don't recall what they were, but i *do* remember they seemed like a good idea ;)17:41
*** flepied has quit IRC17:42
corvustristanC, pabelanger, tobiash, mordred: i've left a long review on https://review.opendev.org/660856 -- i'd like us all to think about this one a bit.17:44
corvuspabelanger: small -1 on 66337817:48
tobiashSpamapS: using github that's not possible (is using app auth)17:50
*** gtema_ has quit IRC17:50
tobiashcorvus: wow17:53
corvustobiash: what's not possible?17:53
mordredtobiash: github disallows app auth from pushing changes?17:53
tobiashcorvus: direct push to a protected branch using an app17:54
mordredwow17:54
tobiashyou can restrict pushes to branches only to real users17:54
mordredI suppose a workaround could be to create a normal user account with an ssh key that has push access, yeah? and then tell zuul to use that for pushes?17:54
tobiashmordred: yes, but that sounds like an ugly hack and totally violates the point of using app auth17:55
mordredyup17:55
mordredI agree. it's really sad that github has decided to do that - I'll be disappointed if zuul-push doesn't work for github once we have it implemented :(17:56
corvuswell, it will work, it just may need that workaround17:56
mordredyeah17:56
tobiashgithub has a long standing issue for this and states that they're working on this (since a year or so)17:56
fungimaybe they'll have a solution by the time we do17:57
tobiashthat workaround isn't really workable for large multi tenant deployments, so that at least needs to be optional and disabled by default17:58
fungioh, i entirely expect zuul push to be disabled by default since that would be a significant behavior change to just introduce in an upgrade17:59
*** panda has quit IRC17:59
fungieven for gerrit deployments it would require additional acls17:59
mordredyeah18:00
tobiashcorvus: re trigger, I haven't thought it through fully but could there also be a possibility D where we can derive this decision from the change itself?18:00
*** lennyb has quit IRC18:00
tobiashlike a gerrit change or github pr always need file matcher18:00
tobiashbut a branch change or ref change might not, because they probably never have file changes attached18:00
tobiash(at least if it has'nt an oldrev)18:01
fungi(or a tag, or...)18:01
*** panda has joined #zuul18:01
corvustobiash: yes, we should consider that -- i think the main thing to think about is whether we would ever want a branch head to use a file matcher18:01
fungipretty sure ref-updated events have no files section18:01
fungibut i may be remembering older gerrit18:02
corvusfungi: actually, i think they do...18:02
fungioh?18:02
*** michael-beaver has joined #zuul18:02
tobiashref-updated can have files18:02
fungineat!18:02
corvusand in cases where they don't, we have drivers fetch them.  we use that internally in zuul to update the config18:02
tobiashthey have old-rev and new-rev and thus at least files can be computed18:02
*** mgoddard has quit IRC18:03
tobiashbut something like enqueue-ref could be enqueued in a way that files have no meaning18:03
*** mgoddard has joined #zuul18:03
tobiashand timer trigger also would just enqueue a branch head which should probably never have files18:03
fungiyeah, i think the enqueue-ref rpc subcommand lacks a --old-rev option18:04
fungioh, nope, --oldrev is supported18:04
fungii'm striking out today18:04
fungiit's optional at least (and probably assumes oldrev=0 if unspecified)18:05
*** sshnaidm is now known as sshnaidm|off18:06
fungiseems --newrev is optional too according to the help output18:06
corvusnewrev=0==deletion18:07
fungiahh, yeah, that makes sense18:07
fungitags seem to lack an oldrev: http://zuul.opendev.org/t/openstack/build/2b2596f543764a189238c97d895c439018:08
pabelangercorvus: thanks for both, will dig in more shortly18:09
fungino oldrev for branch updates either http://zuul.opendev.org/t/openstack/build/8d90086e496242f29f7f51c5c98f110b18:09
corvusfungi: https://zuul-ci.org/docs/zuul/user/jobs.html#tag-items18:09
corvusthe docs lay out exactly when each thing is defined18:09
fungioh neat, i hadn't noticed that in the documentation. thorough!18:11
openstackgerritPaul Belanger proposed zuul/nodepool master: Toggle host-key-checking for openstack provider.labels  https://review.opendev.org/66337818:16
pabelangercorvus: mordred: ^updated, thanks again for review18:16
*** mattw4 has quit IRC18:26
*** mattw4 has joined #zuul18:27
openstackgerritDavid Shrewsbury proposed zuul/zuul master: WIP: Add caching of autohold requests  https://review.opendev.org/66341218:39
*** hashar has joined #zuul18:42
openstackgerritDavid Shrewsbury proposed zuul/zuul master: Add autohold-info CLI command  https://review.opendev.org/66248718:48
openstackgerritDavid Shrewsbury proposed zuul/zuul master: Record held node IDs with autohold request  https://review.opendev.org/66249818:48
Shrewspabelanger: that host-key-checking change doesn't just optionally override the pool value, it totally eliminates checking of the pool value18:52
Shrewspabelanger: is that intentional?  the "override" comment in the commit message makes me think it isn't18:53
*** mattw4 has quit IRC18:53
Shrewscorvus: maybe you want to remove your -3 on that until we confirm?18:53
*** mattw4 has joined #zuul18:53
corvusShrews: done18:53
Shrews sorry i didn't get a chance to look until now18:54
corvusShrews: does line 216-217 handle the fallback?18:55
corvusin driver/openstack/config.py18:56
*** jamesmcarthur has joined #zuul18:56
Shrewscorvus:  that sets the pool version of that value, which is never checked18:57
Shrewsi think if he removes the change he made in provider.py, it would work18:57
*** mattw4 has quit IRC18:57
Shrewserr, lemme check something18:57
Shrewsi think the code squashing in gerrit is throwing me off18:59
Shrewscorvus: pabelanger: ok, sorry for the noise. lgtm. i'll add the +3 back19:02
corvusShrews: thanks for the extra check :)19:02
corvusShrews: i also think the test still exercises the case you were worried about (label1_nodes should be that case i think)19:02
Shrewsi saw the +3 and tried to do a hurried review19:03
corvus(i just went and double checked that)19:03
Shrewscool19:03
openstackgerritClark Boylan proposed zuul/zuul master: Update axios version and yarn.lock  https://review.opendev.org/66231619:06
Shrewscorvus: if we ever get a chance to redo nodepool, i want to eliminate the whole "outer label" and "inner label" config concept. It's caused me so much confusion in various scenarios.  But maybe that's just me  :)19:06
clarkbI think it creates confusion but adds some useful flexibility19:07
corvusShrews: i hear you -- functionally it's really useful, but it's confusing.  maybe we can find another way to do it, or maybe we just need new words.19:07
clarkbit allows you to say this ubuntu-xenial-arm64 and that ubuntu-xenial-x86 image provide the ubuntu-xenial generic type to jobs19:07
corvus(and if it's just new words, maybe we can make that change without a big redo)19:08
corvusit's actually probably worse in the code than it is in the configfile19:08
Shrewsyes. that.19:09
corvus(is pl a pool-label or a provider-label or...?  turns out it's a provider-label in a pool.  whatever that is :).19:10
* corvus -> lunch19:10
fungiso much p in that pool19:11
Shrewsboo fungi19:11
* Shrews hopes he's not in the lounge all week19:11
fungii only do the eight o'clock and ten o'clock show19:11
Shrewslol19:12
fungidon't forget to tip your wait staff!19:12
*** jamesmcarthur has quit IRC19:12
SpamapStobiash:well... we could always give Zuul a real user in the GitHub system for pushing purposes.19:12
SpamapSWhich would actually be pretty nice, because you could configure branch protection so only Zuul can push.19:13
tobiashSpamapS: yes, that's a workaround but would not really fit into our operations model19:14
*** jamesmcarthur has joined #zuul19:14
fungiyeah, gerrit already requires an account for zuul to listen to its event stream and post label votes/comments, so it's not as big a difference there19:17
fungibut also has a much more robust and granular rbac model19:17
clarkbfungi: gerrit also requires it to hit the submit button19:17
clarkbso no change in needing an account to hit submit vs force push19:17
fungisure, though that would ni theory go away when enabling the zuul push feature19:18
clarkbwell it needs an account to push right?19:18
fungiyep, that's what i was saying19:18
clarkboh right submit goes away but not the need for an account19:18
fungii see, you mean requiring an account to push is also no different from requiring an account to call the submit api method19:19
fungiwhich i agree with19:19
clarkbyup19:19
*** armstrongs has joined #zuul19:23
*** zbr has quit IRC19:25
armstrongsHey has the aws nodepool driver been tested for Windows hosts. I have it working for fedora and centos ec2 instances but I have updated the connection type and port to winrm and it is falling over at key checking. Am I missing any other steps for Windows vms?19:25
tobiasharmstrongs: I think so far only SpamapS and I tried the aws driver and I think we both didn't test windows on aws19:29
tobiashso it might or might not work probably19:29
tobiashplease note that the aws driver is still in an early state19:30
armstrongsCool I had to update it to support private ips already, I can add the logic for windows vms if you like put in a PR if that's ok.19:33
pabelangertristanC: could you point me in the direction on how to add pagination to the builds page on the dashboard? I've had a few users request that and struggling to figure out how to add it19:35
openstackgerritMerged zuul/nodepool master: Toggle host-key-checking for openstack provider.labels  https://review.opendev.org/66337819:36
tobiasharmstrongs: I'd be happy to see this :)19:39
tobiasharmstrongs: also I have two wip changes to the aws driver: https://review.opendev.org/632712 and https://review.opendev.org/63271519:39
tobiashif that's useful to you19:39
*** hashar has quit IRC19:43
openstackgerritDavid Shrewsbury proposed zuul/zuul master: Add caching of autohold requests  https://review.opendev.org/66341219:43
*** hashar has joined #zuul19:44
*** armstrongs has quit IRC19:47
*** jamesmcarthur has quit IRC19:55
*** jamesmcarthur has joined #zuul19:56
*** rlandy|ruck is now known as rlandy|ruck|brb20:02
*** panda has quit IRC20:04
*** panda has joined #zuul20:05
*** mattw4 has joined #zuul20:07
mattw4Does anyone know why I would see a "DISK_FULL" error reported to Gerrit?  My Zuul containers and test nodes seem to have adequate disk space, but I keep seeing this error: "setup-devstack finger://b191afe1a77a/68a2e1f7034744f8afb37c3f44d20745 : DISK_FULL in 0s"20:08
mattw4in the above ^ context, the "setup-devstack" job inherits from devstack-minimal.20:09
clarkbmattw4: are you sure the executors and mergers have disk available?20:09
mattw4clarkb: I ran a "df -h" inside all the containers and it showed 60+GB available, but is that the correct way to check?20:10
corvusmattw4: what clarkb said and also see https://zuul-ci.org/docs/zuul/admin/components.html#attr-executor.disk_limit_per_job20:11
corvusand https://zuul-ci.org/docs/zuul/admin/components.html#attr-executor.min_avail_hdd20:11
clarkbassuming docker I believe containers get unlimited disk by default20:11
clarkbso df in the container is probably correct20:11
corvusprobably the disk_limit_per_job then20:11
mattw4corvus: how can I inspect how much scratch space consumed per job?  I ran this devstack job a few times yesterday so maybe I'm accumulating logs somewhere?20:12
mattw4clarkb: yeah, it's docker containers20:13
tobiashcorvus: should we rename DISK_FULL to something like DISK_QUOTA or similar?20:13
corvustobiash: maybe so20:13
tobiashI also got complaints why the heck I don't care about full disks as operator...20:13
corvusmattw4: nothing should accumulate -- each job starts with a new scratch space20:13
corvustobiash: YOUR_JOB_USES_TOO_MUCH_DISK_SPACE?  :)20:14
tobiashthat's great ;)20:14
fungiagreed, some opendev users have been confused by DISK_FULL results and have to get explained that their jobs are archiving more data than zuul is configured to allow20:14
fungiMAKE_SMALLER_LOGS20:14
fungi;)20:14
mattw4so how does it work that the job dails before it begins?20:14
corvusmattw4: i'd check the executor logs for clues20:15
mattw4my jobs aren't running at all, just failing with the DISK_FULL error.  Shouldn't it fail AFTER it accumulates a bunch of logs?20:15
mattw4will do corvus20:15
fungimattw4: when i've seen it, yes. maybe the job is accumulating too much in its workspace at the start somehow?20:16
corvusmattw4: yes, that's the typical scenario, since due to use of hard links, we generally avoid counting the git repos against the quota.  so when a job starts, it should only be using a few MB at most.20:16
fungii can't say i've seen jobs instal-fail with DISK_FULL20:16
mattw4it's devstack so it clones a LOT of repos first :/20:16
fungiin the executor workspace though?20:16
fungimaybe the delegation is wrong?20:16
corvusif it's using zuul-provided repos via require-projects, those generally shouldn't count (much)20:16
corvusif it does its own cloning, then, that is almost certainly the problem :)20:16
*** rlandy|ruck|brb is now known as rlandy|ruck20:17
mattw4I don't think I've properly configured Zuul because I'm not using required-projects20:17
mattw4I'm using roles instead20:17
mattw4in by job definitions20:17
mattw4my*20:17
corvusmattw4: oooh20:18
corvusmattw4: you're using devstack-minimal, right?20:18
mattw4corvus: yeah, trying to write a job that inherits from devstack-minimal20:19
mattw4so I added a bunch of untrusted projects (my dependency walk from yesterday) to the tenant config20:19
corvusok.  devstack-minimal inherits from devstack-base which *does* have ERROR_ON_CLONE set to true, so as long as you aren't overriding that, devstack should refuse to clone repos.20:19
openstackgerritDavid Shrewsbury proposed zuul/zuul master: WIP: Auto-delete expired autohold requests  https://review.opendev.org/66376220:20
mattw4and I added {devstack,requirements,cinder} to my required projects in my job definition20:20
*** tjgresha has quit IRC20:21
mattw4so I've configured this incorrectly, haven't I?20:21
corvusmattw4: nah, that all sounds sensible.  let's see what the logs say.20:21
corvusmattw4: the other thing that might be helpful is to watch the streaming log as it's running20:21
fungithere's a command-line flag to the executor to instruct it not to clean up workspaces right? maybe set that and then see what's taking up so much room? --help says it's called --keep-jobdir20:22
mattw4corvus: I found the error you mentioned: 2019-06-06 20:06:19,868 INFO zuul.ExecutorDiskAccountant: /tmp/tmpt5q_a830/68a2e1f7034744f8afb37c3f44d20745 is using 592MB (limit=250)20:22
corvusmattw4: can you grab all the logs for that build and paste them?  (grep for 68a2e1f7034744f8afb37c3f44d20745)20:23
mattw4corvus: you want to see all of the logs, right?  for each container?20:24
*** jamesmcarthur has quit IRC20:24
corvusmattw4: sorry, just grep for "68a2e1f7034744f8afb37c3f44d20745" in the executor logs20:25
mattw4corvus: gotcha, just a sec...20:25
*** jamesmcarthur has joined #zuul20:27
*** jamesmcarthur_ has joined #zuul20:29
mattw4corvus: here's the executor log relating to that build: http://paste.openstack.org/show/752614/20:30
*** jamesmcarthur has quit IRC20:31
*** mattw4 has quit IRC20:31
*** mattw4 has joined #zuul20:31
fungimattw4: you probably want to go to http://paste.openstack.org/ and paste it there, then let us know the url20:32
corvusfungi: i think mattw4 did that20:32
corvushttp://paste.openstack.org/show/752614/20:32
fungioh, yep!20:32
mattw4:)20:32
fungii missed it in the part/join20:32
fungithough he got kicked for flooding20:33
fungisorry for not reading closely!20:33
corvusmattw4: the first time it hits the limit is during the clones, which suggests that there may be a problem with the hard-link system that's used to keep the git repos from taking up too much space20:34
fungiyeah, telltale diskaccountant event in the middle of cloning nova20:34
corvusexactly20:34
tobiashmattw4: maybe the git cache and job dirs are on different filesystems20:34
corvustobiash: i think we default the job dirs to /tmp20:35
fungigood point, if they share the same fs then git will use hardlinks20:35
tobiashin many distros /tmp is a tmpfs20:35
mattw4tobiash: don't all of the containers just share the host fs?20:35
mattw4gotcha20:35
mattw4I will check20:35
tobiashmattw4: containers? so you're running in docker?20:35
tobiashin this case you need to ensure that both are within the same bind mount20:36
corvustobiash: yes, via docker-compose20:36
mattw4tobiash: yeah, I started with the quickstart/docker-compose20:36
tobiashsorry, I didn't read all20:36
corvustobiash: we default git_dir to /var/lib/zuul/executor-git, but we default job_dir to /tmp20:36
tobiashwhat are the volumes we mount in?20:37
corvusconsidering how frequently /tmp is a different filesystem these days, perhaps we should change the default20:37
tobiashalso being on the same filesystem is not sufficient in docker, it also must be in the same bind mount20:37
corvustobiash: neither of those are volumes currently.20:37
mattw4tobiash: I thought the docker-compose.yaml would tell me, but I guess I'm not sure how to determine where they're bind-mounted20:38
tobiashmattw4: then the output of mount inside the executor container would be helpful20:38
fungiwell, even moreso, /tmp and /var are *quite* likely to be different filesystems20:38
tobiashmattw4: every volume is bind mounted20:38
fungiin our (opendev's) deployment, our executors put the git repos and the jobdirs in /var20:39
mattw4tobiash: executor container mount: http://paste.openstack.org/show/752615/20:39
tobiashmattw4: that's it, you see the /var/lib/zuul (git cache is there) mountpoint which makes /tmp (jobs are by default there) a different mountpoint20:41
corvuswhy does /var/lib/zuul appear there?  that's not in the docker-compose file...20:41
tobiash-> no hardlinks20:41
corvusmattw4: did you customize your docker-compose file to add that?20:41
*** hashar_ has joined #zuul20:42
mattw4corvus: I added that directory to hold my SSH keys20:42
*** hashar has quit IRC20:42
mattw4executor container mounts from docker inspect: http://paste.openstack.org/show/752616/20:42
corvusmattw4: there's an existing volume in the docker-compose file you can use for ssh keys20:42
corvus(called 'sshkey' and mounted at /var/ssh)20:44
mattw4corvus: where do I put keys in the host for it to mount there?20:44
*** armstrongs has joined #zuul20:45
corvusmattw4: it's not bind-mounted from the host, so you'll need to copy it into the container20:45
corvus(or, if you want, you could alter the compose file to bind mount a dir in)20:45
corvusmattw4: anyway, if you do that, you can drop the /var/lib/zuul mount which will put /var/lib/zuul/executor-git and /tmp on the same filesystem again and hard links will work20:46
corvusmattw4: or you could alter the "job_dir" setting.  whatever way gets you to the same filesystem.  see the docs here: https://zuul-ci.org/docs/zuul/admin/components.html#attr-executor.git_dir20:47
mattw4corvus: thanks! I will give that a try.  To summarize: the DISK_FULL error was a result of creating an additional mount that them put /var/lib/zuul/executor-git and /tmp on different filesystems?20:48
corvusyep20:48
corvusmattw4: (specifically it's the git_dir and job_dir directories -- those are the default values for those)20:49
*** hashar_ has quit IRC20:50
mattw4corvus: just looked at git history: there's a bind mount defined for scheduler for /var/lib/zuul20:50
corvusmattw4: well, upstream there's a *volume* defined for /var/lib/zuul on the scheduler.  it's not a bind-mount; it's there to persist private key storage.20:51
corvusthose data are to re-creatable.  everything on an executor is, so we didn't persist that in the docker-compose file.20:52
mattw4gotcha.  The git log says I didn't alter the docker-compose so did I break something else or is it that the volume doesn't exist in my VM?20:52
*** armstrongs has quit IRC20:54
*** jamesmcarthur_ has quit IRC21:03
*** jamesmcarthur has joined #zuul21:05
*** jamesmcarthur_ has joined #zuul21:16
*** jamesmcarthur has quit IRC21:18
*** jamesmcarthur_ has quit IRC21:36
*** jamesmcarthur has joined #zuul21:37
*** jamesmcarthur has quit IRC21:46
*** sanjayu_ has joined #zuul23:03
*** jamesmcarthur has joined #zuul23:13
*** jamesmcarthur has quit IRC23:16
*** jamesmcarthur has joined #zuul23:17
*** jamesmcarthur has quit IRC23:42
*** jamesmcarthur has joined #zuul23:45
*** jamesmcarthur has quit IRC23:57

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