| gitlab-br-bot | buildstream: merge request (albfan/gitignore->master: .gitignore: Ignore autogenerated docs) #473 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/473 | 04:29 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (gitignore->master: .gitignore: Ignore autogenerated docs) #464 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/464 | 04:31 |
| *** Prince781 has joined #buildstream | 04:43 | |
| *** Prince781 has quit IRC | 04:53 | |
| *** noisecell has joined #buildstream | 06:17 | |
| gitlab-br-bot | buildstream: merge request (jjardon/doc_sandbox->master: WIP: docs: Fix build with latest version of sphinx) #414 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/414 | 06:53 |
| *** finn has joined #buildstream | 08:05 | |
| *** jonathanmaw has joined #buildstream | 08:16 | |
| *** aday has joined #buildstream | 09:39 | |
| jmac | I'd like to raise a WIP MR for the CAS-backed virtual directory work today. However, at the moment it's a merge of my previous unmerged virtual directory work and juergbi's CAS artifact cache work, so it will be difficult to see my recent changes among the rest of the work. Any idea how to proceed? | 09:39 |
| Nexus | juergbi: any news on CAS? | 09:50 |
| jmac | juergbi doesn't typically do buildstream on Fridays | 09:51 |
| Nexus | i know, just incase he happens to glance | 10:03 |
| Nexus | he's still in the channel, so he might | 10:03 |
| juergbi | jmac: as long as you rebase and keep the dependent commits at the bottom, it shouldn't be too difficult to distinguish | 10:20 |
| juergbi | (when looking at per-commit history instead of overall changes) | 10:20 |
| jmac | OK, if you're happy browsing commits rather than a whole MR, that is fine | 10:21 |
| juergbi | ah, or maybe you could specify my cas branch / your previous virtual directory work as target branch | 10:21 |
| juergbi | even if we won't merge it right now. i think we can change it to master later | 10:21 |
| jmac | I haven't tried that on GitLab before but I'll see what I can do | 10:21 |
| jmac | Otherwise I'll just squash the commits down to something sensible | 10:21 |
| juergbi | I haven't tried it either but it might work | 10:21 |
| juergbi | would also be an option | 10:21 |
| juergbi | Nexus: the CAS MR should be complete. jjardon is planning to put it under test using the freedesktop-sdk | 10:22 |
| * jennis rushes | 10:23 | |
| jennis | lol | 10:23 |
| Nexus | juergbi: ok, so what's the plan regarding using that over splitting the artifact? | 10:23 |
| Nexus | as per the "Stop the train" email chain | 10:23 |
| juergbi | would probably make sense to go straight towards a CAS-based approach | 10:25 |
| juergbi | afaik the splitting approach is not in a MR yet, and the .git/.bzr reduction prerequisite is also not in master yet | 10:25 |
| juergbi | but I can't say for sure when CAS will be merged. will need a review by tristan and he's on holiday | 10:26 |
| jennis | Hi guys, would appreciate some thoughts on the following. I'm looking at determining how much disk space has been used by calling a subprocess which essentially calls `df`, fiddling with the output of this and putting it into a list and parsing the list | 10:26 |
| juergbi | hm, is there no Python API for this? | 10:27 |
| jennis | So essentially looking how much is "used" under "/" | 10:27 |
| jennis | Maybe I haven't looked hard enough, but I thought this may work | 10:27 |
| juergbi | why `/`, not the artifact/cache directory? | 10:27 |
| juergbi | os.statvfs() should work for this | 10:28 |
| jennis | Because of what subprocess(['df' 'h']) returns | 10:28 |
| jennis | Oh, I will look at this, ta juergbi :) | 10:28 |
| Nexus | juergbi: i'm working on pushing a WIP MR for the reduction now :) | 10:29 |
| juergbi | great. that can go in independent of CAS anyway | 10:29 |
| Nexus | cool | 10:29 |
| jennis | mhmm, I remember looking at os.statvfs the other day and iirc what it was returning was very different to what the _get_dir_size() function returned | 10:30 |
| jennis | (the latter function walked through the directory and summed the size of every file | 10:30 |
| jennis | ) | 10:30 |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 10:30 |
| juergbi | jennis: yes, os.statvfs() is a replacement for a `df` subprocess, not a direct replacement for _get_dir_size() | 10:31 |
| jmac | statvfs returns stats about the file system free space, not about the space used by a directory | 10:31 |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 10:31 |
| jennis | Ok, so I guess I'm confused why we specify a path for this | 10:32 |
| juergbi | you may have multiple partitions | 10:32 |
| juergbi | each which their own filesystem and free/used space | 10:32 |
| jennis | ahh ofc, so calling os.statvfs in /home and /home/buildstream for example should return the same, if I understood that correctly | 10:33 |
| juergbi | on typical systems, yes | 10:33 |
| juergbi | in our case we should use the root directory of the artifact cache | 10:33 |
| jennis | Ok, I'll look into this function, ta juergbi | 10:36 |
| jennis | You say use the root dir, atm i'm walking through the directory which is situated at a variable called "repopath", this is just: path/to/ostree/cache, so it seems that calling os.statvfs on this should return the same...? | 10:38 |
| tlater | jennis: Yes, it should, but it may be a bit more robust to call it on the artifact dir (i.e. /buiki | 10:41 |
| tlater | ~/.local/buildstream/artifacts | 10:41 |
| tlater | ^ Note that that is configurable, so whatever the variable that points to it says, of course | 10:42 |
| tlater | It's more robust in case the artifact directory doesn't exist anymore, because implementation changes or somesuch :) | 10:43 |
| jennis | Sorry, the repopath is the absolute path to that directory | 10:43 |
| tlater | Ah, alright, should be fine then | 10:43 |
| jennis | Because on the server we don't have the same dir structure as local | 10:43 |
| tlater | Oh, right, I forgot you were working on the server for a second | 10:43 |
| jennis | hehe | 10:44 |
| *** Trevinho has joined #buildstream | 10:54 | |
| gitlab-br-bot | buildstream: merge request (awacheux/artifact-type-error->master: Fix artifact initialization result tuple) #469 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/469 | 10:55 |
| *** cs_shadow has joined #buildstream | 11:00 | |
| jennis | So I'm thinking with this approach we may not even need the user to set a quota | 11:19 |
| jennis | ^ for the remote server | 11:20 |
| jennis | Rather, I'm thinking, let's just check the free space on the file system, if it's not much, we'll start expiring objects? | 11:20 |
| paulsherwood | jennis: then you need a decision about which objects to expire | 11:21 |
| jennis | We expire the least recently pushed objects | 11:21 |
| paulsherwood | it's not that simple | 11:21 |
| paulsherwood | what if old objects are being used recently? | 11:21 |
| jennis | oh yes, this has been discussed before | 11:22 |
| jennis | Ideally it would be least recently used | 11:22 |
| jennis | however there is currently not a good way to do this with ostree | 11:22 |
| paulsherwood | ybd and kbas both handle culling/cleanup to free space | 11:22 |
| jennis | however, juergbi has mentioned that it is possible with CAS | 11:22 |
| paulsherwood | (fwiw, in case folks want to look at prior examples) | 11:23 |
| jennis | thanks paulsherwood | 11:23 |
| juergbi | yes, with CAS the plan is to remove least recently used | 11:23 |
| paulsherwood | for the client case (ybd), the time clean up is at the start of a run (but fork so we don't hold ourselves up) | 11:24 |
| juergbi | jennis: quota is much better configurability wise as the artifact cache might not be the only (significant) thing in the partition | 11:24 |
| paulsherwood | time to clean up | 11:24 |
| paulsherwood | cleaning up at the end may cause things to be lost that we would rather not lose | 11:24 |
| jennis | ahh, juergbi I've been assuming a server which is *just* an artifact cache | 11:24 |
| juergbi | paulsherwood: our plan for client side is to have two thresholds and start purging if one is reached, which can be at the beginning or in the middle of a session | 11:26 |
| jennis | paulsherwood, as it currently stands, on my branch, we try to push something, check it's size before pushing and if the current cache size + incoming artifact size exceeds the quota, we expire LRP objects until there is enough room | 11:26 |
| paulsherwood | jennis: i don't like that very much... we're in danger of arbitrarily delaying the current push... why not keep ensuring that we (nearly) always have enough room to upload a largest artifact? | 11:27 |
| paulsherwood | but i may be wrong | 11:27 |
| paulsherwood | juergbi: what are the two thresholds? | 11:28 |
| paulsherwood | and how do we define 'middle'? | 11:28 |
| jennis | So before we push, check the size and expire LRP artifacts until we're in a "safe-zone", this kind of approach? | 11:28 |
| tlater | jennis: Rather, I think checkinf *after* the push completes is what paulsherwood suggests | 11:29 |
| paulsherwood | jennis: no, on 'server', always clean up after artifact upload, to ensure enough free space for n inbound largest artifacts (where n is expected number of maximum simultaneous uploads) | 11:29 |
| tlater | I don't think this works with our architecture, unfortunately, since the script terminates with the push command | 11:29 |
| juergbi | paulsherwood: tlater has been working on this, I yet have to check the latest MR, but iirc the thresholds are configurable and we purge in the background when we hit the first threshold, and suspend building if we hit the second threshold | 11:29 |
| juergbi | tlater: with CAS we'll have a persistent server process | 11:30 |
| tlater | juergbi: Yup, it's just not possible with the current implementation jennis is working on | 11:30 |
| juergbi | indeed | 11:30 |
| paulsherwood | tlater: where is the script? on the client? nothing on the server? | 11:31 |
| tlater | paulsherwood: The script is on the server and executed by ssh's ForceCommand setting. I dislike this implementation, it was a hack around ostree | 11:32 |
| paulsherwood | erk :) | 11:32 |
| juergbi | obviously no longer exists in the CAS branch | 11:33 |
| paulsherwood | juergbi: i'm not sure i like the thresholds approach, unless the defaults are "if this can possibly be built, it will be, even if you have to clear out all existing unused artifacts" | 11:33 |
| tlater | paulsherwood: That's how it works :) | 11:34 |
| paulsherwood | ok, i'm misunderstanding 'threshold' then | 11:34 |
| * paulsherwood wonders if tlater is sure about the above | 11:35 | |
| tlater | The upper threshold is when buildstream runs a command to delete artifacts until we only have ~50% of the size left. | 11:35 |
| * tlater is pretty sure this works and has about a gazillion tests to assert it does :) | 11:36 | |
| *** bochecha_ has joined #buildstream | 11:36 | |
| * tlater takes it paulsherwood is wondering about the case in which the artifact is still too big when we're at the lower threshold | 11:37 | |
| tlater | I'm not sure I have a test for that actually, probably worth writing one. | 11:37 |
| paulsherwood | tlater: i'm sorry to seem difficult, but i have prior experience where the actual program behaviour from a user perspective was clearly wrong, in spite of many passing tests | 11:37 |
| paulsherwood | tlater: no, i'm not (quite) thinking about that case | 11:37 |
| * paulsherwood goes to remind himself of what ugliness ybd does, and try to remember why | 11:39 | |
| tlater | paulsherwood: Yeah, user expectation is definitely still a concern, feel free to point out anything you'd find disruptive | 11:41 |
| paulsherwood | i'm happy to, but will it get fixed? :-) | 11:41 |
| tlater | It might, if others agree with your interpretation ;) | 11:42 |
| paulsherwood | before i spend too mcuh time thinking about this... are we *deprecating* the ostree implementation entirely, in favour of the CAS approach? | 11:42 |
| jmac | That's the plan. | 11:42 |
| paulsherwood | tlater: that's a lottery, then :) | 11:42 |
| tlater | Hehe, I'd certainly still appreciate your comments, the branch hasn't landed yet. | 11:43 |
| paulsherwood | ok, so presumably we are only thinking about the new implementation, ignoring the ostree issues? | 11:43 |
| tlater | Not *quite*, for the sake of landing things in order without breaking master we'll probably have to have an intermediate implementation for ostree | 11:44 |
| tlater | This is more relevant to jennis' branch, since I think ostree will remain an option for the local cache in certain environments. | 11:45 |
| juergbi | no, that's not planned | 11:46 |
| juergbi | to land the expiry branches now, they have to work with ostree, of course | 11:47 |
| juergbi | however, when thinking about long term user experience, we can ignore ostree limitations | 11:47 |
| jennis | I still don't see the need for a quota on the server's artifact cache. Can we not just address the fact that once a server (which hosts an artifact cache) runs out of free disk space, we expire the artifact cache until there is room for the incoming artifact | 11:47 |
| juergbi | not sure, we'll have to discuss this | 11:48 |
| juergbi | for the initial implementation, I'd definitely be fine with just relying on free disk space | 11:48 |
| juergbi | i.e., we can discuss this later | 11:48 |
| jennis | Ok, I should be able to implement this today, but I'll keep the commits that allow the user to set a quota | 11:49 |
| jennis | Then we can discuss further on mondya | 11:49 |
| jennis | Tuesday* | 11:49 |
| juergbi | ok | 11:49 |
| jennis | :p | 11:49 |
| *** Prince781 has joined #buildstream | 13:21 | |
| *** tiagogomes has joined #buildstream | 13:29 | |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 13:37 |
| *** toscalix has joined #buildstream | 13:50 | |
| *** tiago_ has joined #buildstream | 13:50 | |
| *** tiagogomes has quit IRC | 13:51 | |
| *** Prince781 has quit IRC | 14:09 | |
| *** Prince781 has joined #buildstream | 14:15 | |
| *** xjuan has joined #buildstream | 14:19 | |
| *** toscalix has quit IRC | 14:21 | |
| *** Prince781 has quit IRC | 14:22 | |
| gitlab-br-bot | buildstream: merge request (albfan/gitignore->master: .gitignore: Ignore autogenerated docs) #473 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/473 | 14:39 |
| *** toscalix has joined #buildstream | 14:41 | |
| albfan[m] | juergbi: finally ^^ | 14:42 |
| gitlab-br-bot | buildstream: merge request (richardmaw/cache-fail->master: WIP: Store failed builds in the cache) #475 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/475 | 14:51 |
| *** xjuan has quit IRC | 14:58 | |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 15:01 |
| *** Prince781 has joined #buildstream | 15:02 | |
| *** tristan has joined #buildstream | 15:02 | |
| *** noisecell has quit IRC | 15:16 | |
| gitlab-br-bot | buildstream: merge request (albfan/gitignore->master: .gitignore: Ignore autogenerated docs) #473 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/473 | 15:18 |
| *** jennis has quit IRC | 15:26 | |
| *** tiago_ has quit IRC | 15:26 | |
| *** jonathanmaw has quit IRC | 15:27 | |
| *** toscalix has quit IRC | 15:35 | |
| *** tiago has joined #buildstream | 15:44 | |
| *** xjuan has joined #buildstream | 15:58 | |
| *** tiago has quit IRC | 16:02 | |
| *** tiago has joined #buildstream | 16:02 | |
| *** solid_black has joined #buildstream | 16:03 | |
| *** tiago has quit IRC | 16:08 | |
| *** jonathanmaw has joined #buildstream | 16:24 | |
| albfan[m] | nice! juergbi I miss to make more clear that https://buildstream.gitlab.io/buildstream/examples_flatpak_autotools.html project sources are on https://gitlab.com/BuildStream/buildstream/tree/master/doc/examples/flatpak-autotools, what do you think? | 16:26 |
| *** aday has quit IRC | 16:35 | |
| *** aday has joined #buildstream | 16:36 | |
| *** solid_black has quit IRC | 16:38 | |
| juergbi | albfan[m]: there is a note about it already. do you think it's at the wrong place (too far down)? | 16:59 |
| *** jonathanmaw has quit IRC | 17:00 | |
| albfan[m] | juergbi: exactly. Sonething like: complete example is here, now let ?me describe to you. I find at least it should be a link. | 17:36 |
| *** Prince781 has quit IRC | 18:06 | |
| *** Prince781 has joined #buildstream | 18:07 | |
| *** Prince781 has quit IRC | 18:31 | |
| *** Prince781 has joined #buildstream | 18:38 | |
| *** aday has quit IRC | 19:00 | |
| *** aday has joined #buildstream | 19:13 | |
| *** aday has quit IRC | 19:16 | |
| *** Prince781 has quit IRC | 19:26 | |
| *** Prince781 has joined #buildstream | 19:40 | |
| *** Prince781 has quit IRC | 19:51 | |
| *** Prince781_ has joined #buildstream | 19:52 | |
| *** Prince781_ is now known as Prince781 | 19:52 | |
| *** Prince781 has quit IRC | 19:54 | |
| *** Prince781 has joined #buildstream | 19:55 | |
| *** xjuan has quit IRC | 20:24 | |
| *** aday has joined #buildstream | 20:43 | |
| *** aday has quit IRC | 20:49 | |
| *** aday has joined #buildstream | 20:54 | |
| *** aday has quit IRC | 21:00 | |
| *** aday has joined #buildstream | 21:04 | |
| *** bochecha_ has quit IRC | 21:11 | |
| *** bochecha_ has joined #buildstream | 21:14 | |
| *** aday has quit IRC | 21:23 | |
| *** bochecha_ has quit IRC | 21:24 | |
| *** cs_shadow has quit IRC | 21:39 | |
| *** aday has joined #buildstream | 21:52 | |
| *** aday has quit IRC | 22:01 | |
| *** Prince781 has quit IRC | 22:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!