IRC logs for #buildstream for Tuesday, 2020-03-31

*** delli3 has quit IRC00:16
*** delli3 has joined #buildstream00:17
*** delli3 has quit IRC00:25
*** delli3 has joined #buildstream00:28
gitlab-br-botjjardon opened issue #1279 (CI is failing: "ERROR: Preparation failed: exit status 1") on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/127900:49
*** mohan43u_ has quit IRC00:50
*** mohan43u has joined #buildstream00:50
*** narispo has quit IRC01:02
*** narispo has joined #buildstream01:02
*** delli3 has quit IRC01:18
*** mohan43u has quit IRC02:06
*** mohan43u has joined #buildstream04:39
cphangLooks like this was retriggered by WSalmon and it now passed. Still need to root cause why it's flaky07:24
*** benschubert has joined #buildstream07:47
*** tpollard has joined #buildstream08:04
*** rdale has joined #buildstream08:27
gitlab-br-botjuergbi opened MR !1845 (juerg/platform->master: Improve sandbox configuration handling) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/184508:36
*** santi has joined #buildstream08:39
*** tristan has quit IRC08:41
*** lachlan has joined #buildstream09:23
*** tristan has joined #buildstream09:24
*** lachlan has quit IRC10:06
*** lachlan has joined #buildstream10:22
*** lachlan has quit IRC10:33
*** lachlan has joined #buildstream10:43
*** ChanServ sets mode: +o tristan11:04
tristanOnly one runner these days ?11:04
tristanjjardon, ^^^ ?11:04
jjardontristan: you need to ask anyone from the infra team https://gitlab.com/BuildStream/infrastructure/infrastructure/-/wikis/home11:06
jjardontristan: but it seems like  a bug11:06
tristanvalentind, ^^^ ?11:06
jjardonthe bastion should spin up runners on demand11:06
tristanI've got one pipeline I've pushed, and they are all waiting on digitalocean-bastion-x86_64 (#483969)11:07
jjardonok, then maybe the bastion is down11:07
tristanHmmm, maybe I'm wrong, looks like they are slowly coming to life, but they all seem to say the same runner :-S11:09
*** lachlan has quit IRC11:09
jjardonbenbrown: are you working in the bastion now? ^11:10
juergbinot sure what's going on but I just deleted old runners that somehow weren't shut down11:11
tristanjjardon, I think there is no issue, except the issue that all jobs are reporting the same runner11:11
juergbiit's not behaving properly for a few weeks now11:11
benbrownYeah, getting my bearings. DO did list a total of 77 droplets, unsure if the bastion lost track.11:11
tristanThey all say "on buildstream-bastion a334e492"11:12
benbrownLooks like this machine needs a bit of attention, I'm sure the 5000 directories that don't map to a running machine in ~/.docker/machine/machines doesn't help things11:12
tristan"Running with gitlab-runner 12.0.1 (0e5417a3)"11:12
tristanBut... they *are* processing in parallel11:12
tristanThey also all say "digitalocean-bastion-x86_64 (#483969)" in the UI11:13
jjardonbenbrown: note there is a script to kill stale runners11:13
tristanMaybe there is only one runner but it is allowed to do a few jobs in parallel (in separate dockers) ?11:13
jjardonbenbrown: https://gitlab.com/BuildStream/infrastructure/infrastructure11:14
benbrownYeah I've noticed that, but it doesn't clean up the bastion11:14
jjardonbenbrown: the bastion should always run, but not run any jobs; what you mean by cleaning the bastion?11:15
*** lachlan has joined #buildstream11:18
benbrownTbh I might be barking up the wrong tree, but it's something worth tidying. docker-machine tracks machine config/ssh keys in the directory mentioned above, with a directory per machine, the 5000+ directories that are present but not removed since machines are removed in DO and not via the bastion are preventing `docker-machine ls` from running. Might not have any influence on docker-machines normal operations.11:19
jjardonbenbrown: oh, by any means that needs to be cleaned up11:20
tristanjjardon, as I recall, the main reason to release 1.4.2 is for python 3.8 support (plus couple bugfixes)11:27
tristanBut nobody added py38 to the CI, and it's looking like it's got failing tests :-S11:28
tristanhttps://gitlab.com/BuildStream/buildstream/-/jobs/49236387511:28
tristanSo lets put that on ice for a bit, maybe I can solve that today11:28
jjardonsure11:29
* jjardon didn't know no python3.8 tests existed for the bst-1 branch11:29
tristanjjardon, they are the same tests for all python versions11:30
tristanThere is a py38 docker image in use in master11:30
tristanI added that to the list and it breaks (so far) on the cache key test11:30
tristanAh, I read your last statement without the word "no" :)11:31
jjardontristan: yeah, I meant that :)11:31
* jjardon reads again and his sentence was not clear at all11:32
tristanNah I'm just a bit dyslexic :)11:32
tristanAha, pip source tests also broken11:35
tristandid we land this without running the test suite ? seems unlikely11:35
tpollardThere may changes landed in master that can be backported for 3.8 changes11:37
*** santi has quit IRC11:39
*** santi has joined #buildstream11:39
tristantpollard, yes there were already but I'll try to search there11:54
tpollardindeed, but if it wasn't tested against the full test suite...12:05
tristanYeah I just did a search through that12:06
tristaninterestingly in 1.4, pip source plugin is whining about "Unable to find a suitable pip command"12:06
tristanAnd in master, _PYTHON_VERSIONS was not updated to add python3.812:07
*** lachlan has quit IRC12:07
tristanSo for some reason it works in master, or the pip source may accidentally be untested in master, or smth12:07
tristanI suspect it's a similar issue for cache key, it bails out not because of cache key but the `bst show` command itself is failing12:08
tpollardpip source should be tests in master & bst-plugins-experimental currently12:08
tpollard*tested12:08
tristanprobably all 4 tests will work after fixing that12:09
valentindSorry, I was having lunch. Do you still need help with the builders?12:09
* tristan is using the same docker image as in master12:09
tristanvalentind, as I understand, the same runner is indeed running multiple jobs in parallel, but I don't understand the runner setup correctly12:10
tristanat first I was worried because the messages all indicate the same runner12:10
tristanI don't know if that is intentional, others seem to think it is not12:10
valentindI will ssh to see.12:11
valentindWell it is creating them now.12:14
valentindIt might just delete them.12:15
tristanvalentind, Do you know why they all say "buildstream-bastion a334e492" in the beginning of their output, and they all say "igitalocean-bastion-x86_64 (#483969)" in the gitlab UI ?12:16
valentindThis is normal.12:16
tristanvalentind, e.g. for this: https://gitlab.com/BuildStream/buildstream/pipelines/13141352412:16
tristanSo how do we know if it's using more than one runner or not ?12:16
benbrownjjardon: I've not seen this before, have you? "cache adapter could not be initialized: missing S3 configuration"12:16
benbrownThe S3 configuration appears to be present12:16
jjardonbenbrown: yeah, I do not think buildstream is using that for cache12:17
valentindAh right they are all on 0e5417a3.12:17
tristanvalentind, At first, it *looked* like it was going to run them all sequentially, but it is processing a few jobs at once at least12:18
tristanvalentind, again I don't know if it is setup correctly12:18
valentindERROR: Docker machine "runner-a334e492-gitlab-runner-autoscale-1584551586-29da6e54" does not exist. Use "docker-machine ls" to list machines.12:18
valentindThis is the issue I think.12:19
tristanSo there is an issue :)12:19
benbrownI don't think that's the root issue12:20
benbrownThose messages seem to appear as a result of failure to create12:21
benbrownAnd the failure to create seems to be because it "Could not create cache adapter"12:21
jjardonbenbrown: IIRC, Ive seen that error when you dont configure S3 cache in the runner toml, but then someone try to use cache: in the the CI YAML12:23
benbrownjjardon: S3 cache is configured in the runner toml, I'm unsure if the credentials are invalid12:24
jjardonbenbrown: oh, then we need to take a look indeed12:25
valentindProbably expired.12:25
valentindThe key is still there12:26
jjardonmaybe a problem with the API (bst uses DO S3, not AWS one; it took me ages to configure exactly as it wanted the first time)12:26
valentindWe have to move the configration entries12:27
valentindThe file format for the configuration seems to have changed.12:27
valentindIt has to be moved to [runners.cache.s3] I think.12:27
jjardonI see12:27
valentindWe should check the documentation.12:28
jjardonguess https://wiki.gnome.org/Projects/BuildStream/Infrastructure is not up-to-date12:28
valentindBut this is not a big deal. I remember seeing this error message before.12:28
jjardonmaybe better to put it in a repo somewhere12:28
jjardonI think benbrown already have some plans for it :)12:28
valentindThe error messages about not being able to create are just old.12:29
valentindMaybe restarting the gitlab-runner would reduce the error messages of old missing machines.12:30
benbrownI was getting the error messages about create during `journalctl -f`12:31
valentindbenbrown, Yes, but I think it tried to create them a long time ago.12:31
benbrownRestarting might help reduce error messages about missing machines though12:31
valentindAnd then it failed with a very long timeout.12:31
valentindThere are no message in the log about the creations of those machines.12:32
valentindOK, I restart to see.12:32
tristanheh, there goes my pipeline ;-)12:33
valentindI retried it.12:33
tristanbut, test_cache_key() passed after adding python3.8 to pip.py's _PYTHON_VERSIONS12:34
tristanGood sign :)12:34
tristanCan't really say why this is not needed in master though12:34
tristanShould probably patch master too for consistency12:35
valentindDoes not make sense.12:35
valentindIt is building. But not on new builders.12:36
tristanHmmm12:37
tristanIt seems it was more snappy to start everything at once12:37
tristanbut I could just be hallucinating12:37
valentindIt seems to be running on existing machines.12:37
valentindMaybe that is fine.12:37
valentindAll the builds seem to be running on a334e492 howeve.12:38
valentindAh that is the bastion. Not an issue.12:38
valentindtristan, It is OK, they run on different builders.12:40
tristanvalentind, cool, thanks for popping in there :)12:41
valentindLook at the line 7: Running on runner-a334e492-project-1975139-concurrent-0 via runner-a334e492-gitlab-runner-autoscale-1585656852-00e32fad...12:41
valentindThe last name is the name of the builder.12:41
tristanI do think performance is better since you restarted12:41
valentindThis is what you have to look at.12:41
tristanah ok12:41
valentindSo here it is 00e32fad12:41
valentindBut if you look at another build, then it has a different name.12:42
tristan5ffde9e4 in the python3.8 test I was interested in12:42
valentindI think it was just gitlab-runner had too much cleanup to do probably.12:42
valentindAnd it was taking a long time.12:42
tristan00e32fad for debian-912:42
valentindBut let's fix the S3 cache.12:43
valentindSomeone is editing the configuration, benbrown? jjardon?12:43
jjardonnot me12:44
valentindhttps://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section12:45
valentindIt explains here what to change,12:45
jjardonyou were rigth: "With GitLab Runner 12.0.0 the old configuration syntax was removed and is no longer supported"12:49
valentindI just wait for whoever is editing config.toml to be finished.12:50
benbrownvalentind: Ah sorry, just had it open in vim12:50
* benbrown may as well have used less for his purposes12:50
gitlab-br-bottristanvb opened MR !1846 (tristan/bst-1/testsuite-py38->bst-1: Pass CI with python3.8) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/184612:50
tristanThere is a merge request for a pip source fix and addition of python 3.8 (for bst-1 branch)12:51
valentindOK, let's see if works better. Maybe we have to restart though.12:51
valentindThat did not fix it. I will restart.12:53
gitlab-br-bottristanvb opened MR !1847 (tristan/pip-source-3.8->master: pip source plugin: Add support for python 3.8) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/184712:57
tristanAnd there is a merge request for doing the same change on pip source for master12:57
valentindERROR: Error creating machine: Error in driver during machine creation: GET https://api.digitalocean.com/v2/droplets/186853180: 429 Too many requests13:01
valentindAt least the S3 error is gone.13:02
*** tristan has quit IRC13:07
gitlab-br-bottpollard approved MR !1847 (tristan/pip-source-3.8->master: pip source plugin: Add support for python 3.8) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/184713:09
*** lachlan has joined #buildstream13:32
*** lachlan has quit IRC13:51
*** lachlan has joined #buildstream13:55
*** mohan43u_ has joined #buildstream14:00
*** mohan43u has quit IRC14:02
*** mohan43u_ has quit IRC14:03
*** mohan43u has joined #buildstream14:03
*** lachlan has quit IRC14:06
*** lachlan has joined #buildstream14:16
*** lachlan has quit IRC14:21
*** lachlan has joined #buildstream15:17
*** lachlan has quit IRC15:42
*** lachlan has joined #buildstream16:08
tpollardI've got an issue where I can wget a tar url on a machine without an issue, but when bst tracks the same url it gets a 403?16:28
*** tpollard has quit IRC16:56
*** lachlan has quit IRC17:02
*** mohan43u has quit IRC17:10
*** lachlan has joined #buildstream17:14
*** mohan43u has joined #buildstream17:14
gitlab-br-botjuergbi opened MR !1848 (juerg/buildbox-run-error->master: _sandboxbuildboxrun.py: Check for buildbox-run initialization errors) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/184817:15
*** santi has quit IRC17:57
*** tristan has joined #buildstream18:01
*** lachlan has quit IRC18:15
*** toscalix has joined #buildstream18:55
*** toscalix has quit IRC19:03
*** tpollard has joined #buildstream19:05
*** mohan43u_ has joined #buildstream19:08
*** tpollard has quit IRC19:08
*** mohan43u has quit IRC19:09
*** rdale has quit IRC19:55
*** benschubert has quit IRC19:58

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