Monday, 2018-06-25

*** spsurya has joined #zuul00:16
*** openstack has joined #zuul01:20
*** ChanServ sets mode: +o openstack01:20
*** nguyenhai has quit IRC05:07
*** Rohaan has joined #zuul05:15
*** nguyenhai has joined #zuul05:15
*** nchakrab has joined #zuul05:27
*** nchakrab_ has joined #zuul05:28
*** nchakrab has quit IRC05:32
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: log-inventory: add missing zuul_info_dir prep  https://review.openstack.org/57767405:33
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Improve logging of GithubTriggerEvents  https://review.openstack.org/57501405:40
*** nchakrab_ has quit IRC05:45
*** nchakrab has joined #zuul05:48
*** Rohaan has quit IRC05:49
*** Rohaan has joined #zuul05:49
*** yolanda has joined #zuul05:53
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: Implement a Kubernetes driver  https://review.openstack.org/53555705:59
*** nchakrab has quit IRC06:02
*** nchakrab has joined #zuul06:03
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: Implement a Runc driver  https://review.openstack.org/53555606:03
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift resource provider  https://review.openstack.org/57066706:09
goerntristanC, github app send the webhook06:10
goernpabelanger, I saw that regex, but from what I see it does not support semver.org?!06:10
goernpabelanger, tristanC what consuses me is that I see there is a job created and finished for the release pipeline, but it doesne seem to do anything06:12
goernI'll get the executor logs...06:12
tristanCgoern: where is that ref coming from? by default we set this one: https://softwarefactory-project.io/cgit/software-factory/sf-config/tree/ansible/roles/sf-repos/templates/config/zuul.d/_pipelines.yaml.j2#n24906:13
tristanCand openstack-infra is using http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pipelines.yaml#n14606:13
goerntristanC, I took the regex from semver.org it should match?!06:14
goernhttps://regex101.com/ seems to match what I want with the regexp from https://github.com/thoth-station/zuul-test-config/blob/master/zuul.d/_pipelines.yaml#L12506:16
tristanCisn't this one missing \. ?06:17
goernja, there is always somewhere a \. missing in a regex :/06:18
goerntristanC, which part do you mean?06:18
tristanCgoern: ^refs/tags/[0-9a-zA-Z\.]+$06:20
goernpabelanger, tristanC here is the executor log, it really says that much... https://paste.fedoraproject.org/paste/1bHBVn6tM77JdRuzrxly7A06:20
tristanCgoern: scheduler log may be more interesting06:21
goerntristanC, please reload https://github.com/thoth-station/zuul-test-config/blob/master/zuul.d/_pipelines.yaml#L12506:21
tristanCdid you add a job to the release pipeline? e.g. in https://github.com/thoth-station/package-extract/blob/master/.zuul.yaml06:22
goernhttps://paste.fedoraproject.org/paste/Hp3bFb0orSotfZKcBS3TUA06:22
goerntristanC, ja https://github.com/thoth-station/srcops-testing/blob/master/.zuul.yaml#L1206:22
tristanCgoern: the scheduler creates a queue item for each event before it figures out if there is any job to run06:22
goerntristanC, what is that ID? Removed job b69b6d1571534382a61e2cbdbfa1b30b06:23
goern it does not relate to any other thing i see?!06:23
tristanCthat seems like an internal id of the apscheduler library06:24
goerntristanC, ok06:25
tristanCis the scheduler running in DEBUG mode ?06:25
goernis gearman involved in a release job? I see an error there... https://paste.fedoraproject.org/paste/mwOG~rCb5CyEHJMavIUluw06:26
goerntristanC, nearly all levels in scheduler-log.yaml are DEBUG, alembic and gerrit is info06:27
tristanCgoern: hum, that reminds me this discussion, i don't think you can attach secrets in project pipeline configuration: http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-January/000215.html06:27
tristanCthe scheduler and the executor are communicating through gearman jobs06:28
tristanCthat ssl exception is benign iirc, and the timestamp doesn't match with your scheduler logs06:29
goerntristanC, right, thats why I ignored it, just wanted to make sure you know all :)06:29
tristanCgoern: there should more logs after the "INFO zuul.Pipeline.local.release: Adding change" line06:30
goernso... the 215.html, I cant understand what Jim is saying... basically... I need to create a upload-pypi job with the secret attached and use that new job in my project's pipeline?!06:30
tristanCyes, put the secret in the same project as the playbooks06:31
tristanCe.g. in your config repo, copy those files: https://softwarefactory-project.io/cgit/config/tree/zuul.d/_jobs-pypi.yaml06:31
goerntristanC, is there a reason to use the _ in the file name?06:34
tristanCgoern: nop06:34
*** nchakrab has quit IRC06:36
*** nchakrab_ has joined #zuul06:36
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: executor: add support for resource connection type  https://review.openstack.org/57066806:56
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-base-jobs master: Add openshift-base job  https://review.openstack.org/57066907:01
*** pcaruana has joined #zuul07:07
*** nchakrab_ has quit IRC07:10
*** nchakrab has joined #zuul07:27
*** gtema has joined #zuul07:30
*** hashar has joined #zuul07:34
*** jpena|off is now known as jpena07:41
*** toabctl has quit IRC07:58
*** Rohaan has quit IRC08:00
*** Rohaan has joined #zuul08:09
*** snapiri- has joined #zuul08:11
tristanCcorvus: can we hope for a nodepool tag today?08:13
*** snapiri has quit IRC08:13
*** toabctl has joined #zuul08:29
*** sshnaidm|off is now known as sshnaidm08:39
*** Rohaan has quit IRC08:42
*** Rohaan has joined #zuul08:44
*** electrofelix has joined #zuul08:58
*** snapiri- has quit IRC08:59
*** snapiri has joined #zuul08:59
*** Rohaan___ has joined #zuul10:54
*** Rohaan has quit IRC10:55
*** sarad has joined #zuul10:59
*** jpena is now known as jpena|lunch11:00
*** nchakrab has quit IRC11:55
*** worldchat has joined #zuul11:55
*** nchakrab has joined #zuul11:58
*** jpena|lunch is now known as jpena12:00
*** dkranz has quit IRC12:02
*** dkranz has joined #zuul12:03
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: build-python-release: ensure LC_ALL is set to en_US.utf8  https://review.openstack.org/57780012:13
*** sarad has quit IRC12:16
goerntristanC++12:21
goernuh, no karma bot :/12:21
*** weshay_ is now known as weshay|ruck12:22
*** nchakrab has quit IRC12:29
*** nchakrab has joined #zuul12:30
*** rlandy has joined #zuul12:32
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix missing dequeue on synchronized pull request variant one  https://review.openstack.org/57735412:32
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix missing dequeue on synchronized pull request variant two  https://review.openstack.org/57735512:32
*** nchakrab has quit IRC12:35
*** gtema has quit IRC12:45
*** nchakrab has joined #zuul12:48
goernwhat does `2018-06-25 12:47:56,883 DEBUG zuul.layout: Pipeline variant <Job upload-test-pypi branches: {MatchAny:{BranchMatcher:master}} source: thoth-station/kebechet/.zuul.yaml@master#0> did not match <Tag 0x7ff258609b70 creates refs/tags/1.0.0-rc.4 on 7d02538c7f692d9dec3977a0009183c05f174a3e>` try to tell me? the tag '1.0.0-rc.4' is pointing to exactly that commit?!12:49
fungi<Tag 0x7ff258609b70 creates refs/tags/1.0.0-rc.4 on 7d02538c7f692d9dec3977a0009183c05f174a3e> is a specific reference object (note the enclosing <>)12:53
fungithe log entry is saying that object didn't match thoth-station/kebechet/.zuul.yaml branch master12:54
fungifor a variant of the upload-test-pypi job with a branch matcher of master12:54
goerngot that, I created a tag via `git tag 1.0.0-rc.4; git push --tags` that should have a master and tag pointing at the same commit, no?!12:55
fungii don't believe tag objects are expected to match any branch, so that's probably benign12:55
*** Rohaan___ has quit IRC12:56
fungibranches are git heads, tags are a different sort of git object12:56
goernconfusing, the same pileline for a different project works with the same git commands12:57
goernI start reckoning why you called it zuul... https://i.kinja-img.com/gawker-media/image/upload/s--xhYIuHnC--/c_scale,f_auto,fl_progressive,q_80,w_800/v6ugnufcmyncheeaxug1.jpg12:58
fungidoes a upload-test-pypi job variant in thoth-station/kebechet/.zuul.yaml include an explicit branch matcher for master? wondering whether this is an explicit or implicit matcher it's logging (i don't spend enough time staring at zuul debug logs)13:00
goernits the matcher from the pipeline not the project13:01
goernfungi, I think you asked about https://github.com/thoth-station/zuul-test-config/blob/master/zuul.d/_pipelines.yaml#L125 ?13:02
fungithe debug log entry you were asking about is specific to the configuration at thoth-station/kebechet/.zuul.yaml13:03
goernja, and there is just jobs https://github.com/thoth-station/kebechet/blob/master/.zuul.yaml#L14 nothing that defines a matcher/regex13:04
fungigot it, so yeah must have been in reference to an implicit matcher (zuul attempts to match configuration based on branches on which it's found since you can have different zuul configuration on different branches of the same project)13:05
goernfungi, ja, thats what tristanC explained, so I made sure no other branch/tag/pr is having a .zuul.yaml13:06
*** acozine1 has joined #zuul13:08
fungilooking through our debug logs, we have lots of tag events and i don't see any mismatches logged like what you have there, so perhaps it is related somehow. where's your job definition for upload-test-pypi reside?13:11
goernfungi, https://github.com/thoth-station/zuul-test-jobs/blob/master/zuul.d/jobs-upload-test-pypi.yaml I spend the morning with tristanC debugging that stuff, generally it works, it seems to be related to that repo13:12
fungiyeah, nothing out of the ordinary in the job definition13:13
goernja, I'm at newbie level :)13:13
fungime too, apparently ;)13:14
tobiashgoern: maybe the post-review flag is guilty: https://zuul-ci.org/docs/zuul/user/config.html#attr-pipeline.post-review13:14
tobiashgoern: check if your pipeline is also marked as post-review13:14
fungiit is, i checked that earlier13:15
fungiand as he said, it's working for one of his other repos13:15
goernhmm... no branch protection on that kebechet repo, I will enable it and repush the tag13:15
fungitobiash: post-review is set for the release pipeline at https://github.com/thoth-station/zuul-test-config/blob/master/zuul.d/_pipelines.yaml#L11713:16
tobiashah ok13:16
goernbranch protection enabled doesnt change anything13:19
fungii'm out of ideas, but more people should be waking up soon too13:20
tobiashgoern: you need at least a reconfiguration to refresh branch protection in zuul13:21
tobiashgoern: is your main.yaml public?13:21
*** acozine1 has quit IRC13:21
fungii wonder whether toggling branch protection fires any events the scheduler can trigger on to know to perform a reconfiguration13:22
tobiashfungi: it doesn't...13:22
tobiashfungi: that was my plan last week until I noticed that there is no way of being notified currently13:23
fungii see, so have to send a manual reconfigure signal to the scheduler or wait for another alteration which would trigger one i guess13:23
tobiashfungi: we can still improve that by rereading the branch protection on push events and pull_request events and trigger tenant reconfigurations if needed13:24
fungiokay, so eventually consistent still, but yes i can see some opportunities to shrink the "eventually"13:24
tobiashyes, a bad compromise but at least some improvement13:25
openstackgerritDavid Shrewsbury proposed openstack-infra/nodepool master: Static driver: fix node registration  https://review.openstack.org/57746413:25
Shrewstobiash: ^^ decided to add some exception handling to that one13:26
tobiashShrews: lgtm13:27
tobiashgoern: is that your tenant config: https://github.com/thoth-station/zuul-test-config/blob/master/zuul/_main.yaml ?13:28
tobiashgoern: that looks at least suspicious because it defines two tenants with the same name13:28
tristanCtobiash: all the zuul/*.yaml files are manually merged13:29
tristanCtobiash: goern: here is the final zuul tenant config: https://paste.fedoraproject.org/paste/iFdX2uFfWfQoACppimLo2Q13:30
openstackgerritFabien Boucher proposed openstack-infra/zuul master: Add tenant yaml validation option to scheduler  https://review.openstack.org/57426513:32
*** fbo has joined #zuul13:33
*** gtema has joined #zuul13:46
tobiashgoern, tristanC: in that case protected branches don't matter as they are not excluded13:47
goernright13:48
goerntristanC, that _main.yaml seems to be a left over...13:49
tristanCgoern: i just pulled it from the configuration endpoint13:50
tristanCgoern: it should be the one that is copied to /etc/zuul/main.yaml13:50
goernshall I copy that to the config repo?!13:51
goern /etc/zuul/zuul.yaml looks good13:51
tristanCgoern: no need, it's generated from the resources, fwiw here is the /manage/v2/configurations/zuul code that software factory uses to generate the zuul tenant configuration: https://softwarefactory-project.io/cgit/software-factory/managesf/tree/managesf/controllers/api/v2/configurations.py#n4913:52
*** acozine1 has joined #zuul13:53
* goern needs to be afk for a few... hrs13:55
goernthanks for the help... brb13:55
*** acozine1 has quit IRC14:03
openstackgerritTobias Henkel proposed openstack-infra/zuul master: WIP: Add pause function to executor  https://review.openstack.org/57782714:04
openstackgerritTobias Henkel proposed openstack-infra/zuul master: WIP: Add pause function to executor  https://review.openstack.org/57782714:15
Shrewsanyone want to push this static driver fix through? https://review.openstack.org/57746414:24
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Add pause function to executor  https://review.openstack.org/57782714:25
*** nchakrab_ has joined #zuul14:27
*** nchakra__ has joined #zuul14:27
*** nchakrab has quit IRC14:29
*** nchakrab_ has quit IRC14:31
Shrewsoh yay, pm spam14:38
*** acozine1 has joined #zuul14:47
*** acozine1 has quit IRC14:48
*** acozine1 has joined #zuul14:48
clarkbtobiash: did you see that I had a preference for variant two? that was one of my original suggestions and I think it owrks here14:49
clarkbits a little hacky but less so than variant one I think14:49
tobiashclarkb: yes I agree14:50
openstackgerritMerged openstack-infra/nodepool master: Static driver: fix node registration  https://review.openstack.org/57746414:51
*** nchakra__ has quit IRC14:54
*** acozine1 has quit IRC15:00
*** worldchat has quit IRC15:02
*** pcaruana has quit IRC15:13
openstackgerritFabien Boucher proposed openstack-infra/zuul master: Add tenant yaml validation option to scheduler  https://review.openstack.org/57426515:27
*** electrofelix has quit IRC15:44
corvusclarkb, fungi, Shrews, tobiash: what do folks think about a nodepool release?  should we restart openstack's nodepool and burn current master in for a bit?16:05
clarkbya I think we should burn it in a bit especially given the fun of the last set of changes we restarted for16:06
Shrewscorvus: we def need a restart to get a bug fix. wanted to do it last week but was bit hampered by pain16:06
fungisounds like a good idea16:06
funginot the pain, but the burn-in16:07
Shrewscorvus: do we want a release note for the static driver pre-register node change?16:08
corvusShrews: you up for doing the restarts today?  and yeah, i think that's note-worthy (desirable but probably not required)16:09
Shrewscorvus: yep, can type a bit better today thx to drugs. will work on a release note first16:10
corvustobiash: i agree with clarkb i like variant two better, but i think we need a note in the source code to prevent us from "fixing" it later :)16:14
tobiashcorvus: I agree :)16:15
openstackgerritDavid Shrewsbury proposed openstack-infra/nodepool master: Add release note for static driver changes  https://review.openstack.org/57785816:16
mordredcorvus: ++ to restart, burn in and release16:16
mordredcorvus: whenever you feel in the mood to look at things, https://review.openstack.org/#/c/551989/ and https://review.openstack.org/#/c/572588 are ready to go16:21
mordredcorvus: no rush, obviously16:21
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix missing dequeue on synchronized pull request variant two  https://review.openstack.org/57735516:23
tobiashcorvus: added the note ^16:23
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix missing dequeue on synchronized pull request  https://review.openstack.org/57735516:24
tobiashand updated the title now that we've chosen a variant16:24
corvusmordred: \o/ on my list :)16:25
tobiashcorvus: ++ for restart, burn...16:26
*** gtema has quit IRC16:41
openstackgerritMerged openstack-infra/nodepool master: Add release note for static driver changes  https://review.openstack.org/57785816:43
*** jpena is now known as jpena|off16:43
corvustobiash, tristanC, goern: is it possible that at the time of the "Pipeline variant ... did not match" message that there was more than one branch in kebechat?  (including potentially a throwaway PR branch?)17:05
corvus(i'm beginning to suspect a bug where we automatically add branch matchers to pipeline variants where we should not)17:08
corvusone way to tell might be to see if there were any other "Pipeline variant ... did not match" messages nearby17:16
goerncorvus, hmm, might be, there have been branches, but none with a .zuul.yaml17:29
*** myoung is now known as myoung|biab17:33
corvusgoern: that's enough to change zuul's behavior.  do you have access to more of those logs so we can see if there's another "Pipeline variant" message near the one you pasted?17:34
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Don't add implied branch matchers to project-pipeline variants  https://review.openstack.org/57788117:34
corvusgoern: ^ i suspect that's the issue, but those messages would help confirm17:35
corvusgoern: oh, actually...17:35
corvusgoern: if there were other branches, but no .zuul.yaml files in them, then we won't see any other "Pipeline variant" messages.17:35
corvusi think the only way to confirm would be to go back to the last reconfiguration and see what branches zuul saw then.  that's more difficult; may not be worth it.17:36
corvustristanC, tobiash, fungi:  https://review.openstack.org/577881  may be fix for issue goern reported17:37
fungicorvus: thanks!17:42
pabelangerq: have we discuss about adding a hard cap to the number of jobs an executor can run at once, outside of the load_multiplier / min_avail_mem settings? The use case is disk_limit_per_job is capped at X , but number of jobs X disk_limit_per_job is greater then local HDD and don't see a way to stop launching more jobs17:50
goerncorvus, coolio! thx17:52
corvuspabelanger: are you saying that you are seeing your executors use up all their disks?17:53
pabelangercorvus: yes, single executor in this case17:54
goernoh man... `Project thoth-station/zuul-test-jobs not in pipeline <Pipeline post> for change <Branch 0x7f3ef05e13c8 refs/heads/master updated 7d380222da963403bab1182ac4dc60fe1b6fb935..df9057443fa8e165303aeace76fee94619eb692a>` :)17:54
goernnot in pipeline? that means that zuul-test-jobs is not in /etc/zuul/main.yaml?17:55
*** harlowja has joined #zuul17:55
goernsee https://paste.fedoraproject.org/paste/KEtyP6zAgHs2kVxntq~u-A17:56
corvuspabelanger: i don't believe we have a governor that looks at total available space.  maybe write one?17:56
corvuspabelanger: (something that unregisters for work when free disk is < X %)17:56
corvusgoern: that means there's no "post:" section in https://github.com/thoth-station/kebechet/blob/7d02538c7f692d9dec3977a0009183c05f174a3e/.zuul.yaml17:57
pabelangercorvus: yes, that would also work too17:58
goerncorvus, thats ok, its a different repo. the config repo: https://github.com/thoth-station/zuul-test-jobs17:58
goerntristanC and I fiddled round with the shadow of the config repo I think17:58
tobiashpabelanger: if you want to implement a disk space governer you should stick that on top of 54927517:59
pabelangertobiash: sure18:00
corvusgoern: ah, well if there's a pipeline definition for that repo (i don't see one), then that message just means there are no post jobs for it.18:03
goernmaybe that is a software-factory related issue... I will talk to tristanC18:04
corvusgoern: it also may not be an issue18:05
corvusgoern: unless you wanted something to happen when you merged a change to that repo18:06
goerncorvus, ja, that was the case... pushes to that repo reconfigured zuul ;)18:06
corvusgoern: that's expected and should be automatic with no configuration needed.  but, for example, the only actual post jobs we have on our "zuul-jobs" repos in openstack are jobs which build and publish the job documentation.  since those repos don't appear to be set up to build documentation, i'm not sure there's any jobs which should be run under those circumstances.18:08
goernah understood, than there is something broken :/18:10
corvusgoern: i don't know -- let me back up and ask for a more complete bug report about what did or did not happen as you expected :)18:11
goernand I think its related to what we did on the server18:11
goerntristanC, asked me to rsync the openstack-jobs repo and commit it back to the local git repo, I guess that is out of sync now with that we got on github18:12
pabelangertobiash: how large is your zuul-merger by chance?18:13
pabelangerSpamapS: ^18:14
pabelangercurious if anybody is using 1GB mergers18:14
pabelanger(ram)18:14
SpamapSpabelanger: I have no dedicated merger18:15
SpamapSI just have the one 16GB box that does all except zk18:15
corvusgoern: i may not have all the necessary information -- but perhaps this will help -- the 'git driver' which is probably what is being used to talk to the 'local git repo' only checks for updates every 2 hours by default.  manually triggering a full reconfiguration would force an update though.18:15
pabelangerSpamapS: ack, thanks18:15
SpamapSand merges in executor18:15
goerncorvus, ack18:17
tobiashpabelanger: have to look it up, just a sec18:18
pabelangerI actually wonder if we could get away with 512Mb for a dedicated merger18:20
pabelangerlooking at http://cacti.openstack.org/cacti/graph.php?action=view&local_graph_id=1522&rra_id=all could be18:20
pabelangerwill have to test and see18:20
SpamapSI think you could18:21
SpamapSexecutor itself is pretty light on RAM usage.18:22
SpamapSit's just the ansible's that use up RAM18:22
tobiashpabelanger: I have three merger pods running with a limit of 1500mb each18:22
tobiashthey currently take 400, 600 and 1400 mb18:22
clarkbpabelanger: the complexity and size of the git merge itself will determine memory usage of that process for the most part18:23
pabelangertobiash: thanks for the info18:26
pabelangerclarkb: agree18:26
pabelangerI think I'll ask for 1GB per new zuul-merger and see how that works18:26
SpamapSI've never charted that, but git's memory uage during a complex merge may not show up on aggregate graphs if it spikes up.18:30
*** sshnaidm is now known as sshnaidm|afk18:41
*** pcaruana has joined #zuul19:27
*** yolanda has quit IRC20:01
*** yolanda has joined #zuul20:01
*** myoung|biab is now known as myoung20:17
*** pcaruana has quit IRC20:43
fungipabelanger: corvus: nice thing about the disk space % governor idea is that you don't need to fiddle with matching caps to various disks if your executors aren't homogeneous, and with hotplug disks and online resize you also don't need to make config adjustments and restart the executors when you give them more space20:47
*** goern has quit IRC21:01
*** goern has joined #zuul21:01
*** EmilienM has joined #zuul21:03
*** tobiash has quit IRC21:03
*** EmilienM_PTO has quit IRC21:04
*** harlowja has quit IRC21:04
*** EmilienM has quit IRC21:04
*** EmilienM has joined #zuul21:04
*** tobiash has joined #zuul21:05
corvusfungi: yep, the goal for the governors is to be as automatic as possible (let computers do the tuning so sysadmins can sit on the beach, or whatever it is we do)21:17
*** hashar has quit IRC21:48
* fungi was actually sitting by the water, slow-cooking hot dogs and corn in the smoker21:51
fungiunfortunately it's now time to do battle with the lawn21:51
*** harlowja has joined #zuul22:14
*** yolanda_ has joined #zuul22:21
*** yolanda has quit IRC22:22
*** yolanda__ has joined #zuul22:28
*** yolanda_ has quit IRC22:31
tristanCpabelanger: i think there is another issue regarding to the DiskAccountantDiskAccountant, it seems like it shouldn't be running for merge jobs22:46
tristanCwhere the disk_limit_per_job value is actually used for all the git data cached by merger job. Once the cache pass the limit, then the Accountant constantly printing info messages.22:48
fungii seem to recall the zuul project had some boards in sb which were very slow to load. was https://storyboard.openstack.org/#!/board/53 one of them?23:21
fungidhellmann just contributed a db indexing fix for storytags23:22
fungiseveral orders of magnitude speedup on the primary query23:22
clarkbnice and quick23:34

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