IRC logs for #buildstream for Friday, 2019-12-06

*** narispo has quit IRC02:14
*** narispo has joined #buildstream02:14
*** traveltissues has joined #buildstream06:32
*** traveltissues has quit IRC06:35
*** traveltissues has joined #buildstream06:47
*** traveltissues has quit IRC06:51
*** traveltissues has joined #buildstream07:47
*** santi has joined #buildstream09:43
*** santi has quit IRC09:47
*** santi has joined #buildstream09:51
*** santi has quit IRC09:51
*** santi has joined #buildstream09:54
*** tiagogomes has joined #buildstream09:58
*** phildawson_ has joined #buildstream10:08
*** bochecha has joined #buildstream10:19
*** lachlan has joined #buildstream10:29
benschuberttlater[m]: you were looking at the benchmarking stuff a bit right? Is it 'available' for PRs? :)10:39
*** lachlan has quit IRC10:40
tlater[m]benschubert: Not sure what benchmarking stuff you mean10:42
tlater[m]Do you mean the bot?10:42
benschubertyes !10:43
tlater[m]lachlan would know more, seems he's not here right now - the bot is still heavily WIP, might or might not be currently up, let me see if I can figure out whether it'd work right now :)10:43
benschubertthanks!10:43
*** lachlan has joined #buildstream10:44
tlater[m]ah, lachlan, we were just talking about you :D10:44
benschuberto/10:49
lachlanbenschubert: Which MR would you like to benchmark?10:49
benschubertlachlan: I haven't made it yet, give me a minute :)10:50
lachlanbenschubert: If you can let me know when it is created and the buildstream pipeline completes successfully.10:51
benschubertsure, thanks :)10:51
*** cs-shadow has joined #buildstream10:52
gitlab-br-botBenjaminSchubert opened MR !1755 (bschubert/optimize-scheduling->master: scheduler.py: Optimize scheduling by not calling it unnecessarily) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175510:54
*** santi has quit IRC11:15
*** santi has joined #buildstream11:15
benschubertlachlan: oh thanks!11:29
coldtomwhat is the recommended way to say "don't push during this build" these days?11:48
tlater[m]coldtom: afaik it's still --pushers 011:48
*** lachlan has quit IRC11:49
coldtomah, that makes this job slightly concerning: https://gitlab.com/celduin/burn-sdk/-/jobs/37157201111:53
coldtom(build is run with --pushers 0)11:54
coldtomon a semi-related note, is there any plan to specify some elements should not be pushed? e.g. I don't want my remote cache to be full of enormous top-level artifacts12:00
persiaIt's hard to have a sensible default for that.  I have a use case where I mostly only care about having enormous top-level artifacts in my cache.12:02
coldtomsure, i meant a switch that can be put somewhere12:02
coldtomwith default to push thigns12:02
coldtommaybe in element config a "push: false"12:02
tlater[m]coldtom: You mean something like `bst push --except`?12:03
tlater[m]Oh, I see12:03
tlater[m]No plans for that yet12:03
tlater[m]I think the current suggestion for that would be to disable pulling and push what you want manually12:03
persiacoldtom: Any suggestions on "somewhere"?  I don7t think it belongs in the project config, because differnt users of the same project may have different goals.  I am also not sure it belongs in user config, because managing that for many projects quickly gets unwieldy.12:03
coldtomit would also be useful for if you need to depend on proprietary blobs you can't cache12:03
benschubertcoldtom: I woul dbe very careful about putting that in the element config, because downstream people might be wanting different things. If we ever implement that I'd rather have that at user's config level12:03
tlater[m]But I agree that's a little cumbersome if it's a small set of elements you want to avoid pushing.12:03
tlater[m]benschubert: project config level could work too; users can always override that, and I suspect specific projects will dislike pushing certain things, rather than specific users.12:04
benschubertIf you want to avoid pushing big artifacts: putting an nginx in front of your cache that only accepts requests <100Mo is one way, you'll always try to push 100Mo though12:04
persia(another viewpoint here is that of the cache administrator, who may have different costs/capacities/whatever for different size artifacts)12:04
tlater[m]Maybe project+artifact cache config12:05
benschubertone reason I could see this valid though is for proprietary blobs you cannot redestribute12:05
benschubertand those you would _never_ want them in a cache in the open12:05
* tlater[m] thinks project + cache config therefore makes a lot of sense12:06
tlater[m]So you can push your element to the local non-public cache12:06
tlater[m]But avoid throwing it into the open cache :)12:06
persiabenschubert: Ooh.  That's exciting.12:08
benschubertAnd currently, it would be a huge problem unless you use 'lcoal files', but there is a thread on the ML that wants to change this handling which would force us to have to consider this use case. Also, what about RE? :'D12:10
tlater[m]Oh, right, RE will push things to all kinds of places :|12:11
persiaTo my mind, RE implies everything is pushed to cache.12:11
persiaBut that might not be a public cache (depends on how the RE is hosted)12:11
benschubertCorrect, then should we have a provision to prevent RE on some servers for some elements? It might become quickly cumbersome12:11
gitlab-br-bottraveltissues opened (was WIP) MR !1753 (traveltissues/remove-unused-functions->master: remove unused functions 1/2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175312:12
persiaI'm not sure how BuildStream could differentiate between RE-with-private-cache and RE-with-publlic-cache12:12
persiaIt's just an endpoint.  Same interface either way.12:12
coldtomperhaps this config could be in cache configuration12:13
tlater[m]coldtom: Yeah, I think that'd be best12:14
benschubertjuergbi: https://gitlab.com/BuildStream/buildstream/merge_requests/1756 I would still need to do some benchmarks, but I believe we should put this in to follow Python's documentatino12:17
persiacoldtom: My concern is that the accessibility of a network cache can change without notice to the client.12:17
juergbibenschubert: haven't reviewed it in detail but makes sense. I don't think it's relevant for the current child watcher implementation (doesn't use threads, afaik) but we should follow the API spec12:21
*** bochecha has quit IRC12:22
*** bochecha has joined #buildstream12:22
* tlater[m] agrees, assuming benchmarks don't show this is significantly slowr12:23
*** lachlan has joined #buildstream12:25
benschuberttlater[m]: agreed, guess I'll have to do some heavy benchmarking in the next days :'D12:26
benschubertlachlan: https://gitlab.com/BuildStream/benchmarking/benchmarks/-/jobs/371620231 doesn't seem good? :'D12:27
lachlanHistorical issues with the stable release and baserock build, expected12:29
benschubertoh :) good, thanks!12:29
*** traveltissues has quit IRC12:32
*** santi has quit IRC13:14
*** santi has joined #buildstream13:51
lachlanbenschubert: Benchmark complete, MR updated14:08
lachlanI will be taking the bot offline though14:08
*** lantw44 has quit IRC14:09
benschubertlachlan: oh thanks!14:09
lachlanAt the minute you will need to pick through the CSV file for the meaningful results14:10
benschubertok! thanks :)14:13
benschubertmmh it seems to be 2 seconds slower :(14:13
*** lachlan has quit IRC14:16
*** phildawson-ct has joined #buildstream14:20
tlater[m]benschubert: Is that 2 seconds on the build?14:21
benschubertseems like it14:21
* tlater[m] wonders if we can sacrifice 2 seconds for that14:21
tlater[m]It's like a 0.5% increase, isn't it?14:21
benschubertthe benchmarked PR was !1755 not the other one :(14:21
gitlab-br-botMR !1755: WIP: scheduler.py: Optimize scheduling by not calling it unnecessarily https://gitlab.com/BuildStream/buildstream/merge_requests/175514:21
tlater[m]Ah14:21
benschubertso I _expected_ an optimization on this one for builds14:21
*** phildawson_ has quit IRC14:21
benschubertI still want to do my own testing there14:22
tlater[m]It's not a bad idea. We don't do warmup runs on the bot atm, so the variance is a little larger than what you're probably used to14:22
tlater[m]Yeah, standard deviation is about a second, so it might just be outliers14:23
benschubertand only 4 builders right?14:26
benschubertI'm more interested in 8-16-32-64 :D14:27
* tlater[m] doesn't know about the builders14:28
*** lachlan has joined #buildstream14:54
*** bochecha has quit IRC15:06
*** bochecha has joined #buildstream15:06
*** lantw44 has joined #buildstream15:08
gitlab-br-botcs-shadow opened MR !1758 (chandan/remote-setuppy-test->master: Drop support for `setup.py test`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175815:22
*** lantw44 has quit IRC15:24
*** lantw44 has joined #buildstream15:33
gitlab-br-botBenjaminSchubert approved MR !1753 (traveltissues/remove-unused-functions->master: remove unused functions 1/2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175315:35
*** lachlan has quit IRC15:38
gitlab-br-botcoldtom opened MR !1759 (coldtom/fix-junction-remotes->master: _project.py: Allow junctions to use parent remote) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175915:42
*** santi has quit IRC15:43
*** lachlan has joined #buildstream15:56
*** bochecha has quit IRC16:04
*** lachlan has quit IRC16:15
gitlab-br-botBenjaminSchubert approved MR !1759 (coldtom/fix-junction-remotes->master: _project.py: Allow junctions to use parent remote) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/175916:16
*** lachlan has joined #buildstream16:31
benschuberttlater[m]: https://gitlab.com/BuildStream/buildstream/merge_requests/1755 look at the benchmarks, I need to rerun them on my desktop at home but...16:39
*** lachlan has quit IRC16:40
tlater[m]Oh, wow, that's a lot faster16:40
benschuberto/16:41
tlater[m]I really wonder why the other benchmarks don't show that...16:41
benschubertthat was on a VM though, I need real hardware to double check but I think that's one of the best perf improvement we got since february in terms of scheduling16:41
tlater[m]Especially because the parallelism seems to improve a fair bit :)16:42
benschubertYep, I'll try 32 probably now :)16:43
* tlater[m] wonders why the benchmarking bot's results don't show this16:44
tlater[m]It might be less affected, iirc it's like a 2 core machine16:44
benschubertrigh, I'm running on a 32 core one16:44
*** santi has joined #buildstream16:52
*** phildawson-ct has quit IRC16:54
*** phildawson has joined #buildstream16:55
*** lantw44 has quit IRC17:16
*** lantw44 has joined #buildstream17:19
benschubertcoldtom: btw since you worked on the source tests, I sent an email to the ML, you might have other insights17:23
*** lantw44 has quit IRC17:28
*** lachlan has joined #buildstream17:33
*** lantw44 has joined #buildstream17:38
*** lachlan has quit IRC17:42
*** rdale has quit IRC17:43
*** santi has quit IRC17:48
*** lachlan has joined #buildstream17:52
*** lachlan has quit IRC18:01
*** lachlan has joined #buildstream18:18
*** lachlan has quit IRC18:21
*** tiagogomes has quit IRC18:54
*** cs-shadow has quit IRC19:32
*** narispo has quit IRC21:49
*** narispo has joined #buildstream21:49
*** narispo has quit IRC21:58
*** narispo has joined #buildstream21:58
*** narispo has quit IRC22:01
*** narispo has joined #buildstream22:05
*** narispo has quit IRC23:09
*** narispo has joined #buildstream23:09

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