| Walkerdine | I got a SSD drive for my jetson today so I'll finally be able to build my own image | 00:37 |
|---|---|---|
| *** zoli__ has joined #baserock | 00:54 | |
| *** zoli__ has quit IRC | 00:58 | |
| *** zoli__ has joined #baserock | 04:52 | |
| *** petefoth has quit IRC | 05:10 | |
| *** zoli__ has quit IRC | 05:40 | |
| *** zoli__ has joined #baserock | 05:59 | |
| *** petefoth has joined #baserock | 06:24 | |
| *** zoli__ has quit IRC | 06:50 | |
| paulsherwood | Walkerdine: i like your optimism :) | 07:12 |
| *** CTtpollard has joined #baserock | 07:31 | |
| *** petefoth has quit IRC | 07:33 | |
| *** petefoth has joined #baserock | 07:35 | |
| *** zoli__ has joined #baserock | 07:41 | |
| *** rdale has quit IRC | 07:47 | |
| *** tiagogomes_ has joined #baserock | 08:01 | |
| *** mdunford has joined #baserock | 08:03 | |
| *** edcragg has joined #baserock | 08:04 | |
| *** Kinnison has joined #baserock | 08:19 | |
| *** franred has joined #baserock | 08:22 | |
| *** jonathanmaw_ has joined #baserock | 08:25 | |
| *** rdale has joined #baserock | 08:29 | |
| *** toscalix_ has joined #baserock | 08:36 | |
| wdutch | Kinnison: I know you were not working but I don't suppose you learned anything useful this weekend regarding LAVA? | 08:41 |
| Kinnison | Sadly I didn't learn anything significant other than that one of the primary LAVA developers very much likes Milton Pegasus | 08:41 |
| wdutch | hehe | 08:41 |
| * paulsherwood learned that there is a new contender... https://github.com/qca/boardfarm | 08:41 | |
| * wdutch will continue researching buildbot for now | 08:42 | |
| Kinnison | Hmm, boardfarm looks fairly lightweight | 08:52 |
| * paulsherwood prefers lightweight, until heavy is proved necessary | 08:53 | |
| Kinnison | A brief scan through boardfarm's code leaves me worried that it's really quite brittle | 08:58 |
| paulsherwood | define brittle? | 08:58 |
| Kinnison | A lot of its core behaviour appears to be 'expect' driven which isn't the most flexible of behaviours | 08:59 |
| Kinnison | The networking setups it does seem to be hard-coded into its source | 08:59 |
| Kinnison | rather than as configuration | 08:59 |
| paulsherwood | easy enough to fix the latter? and maybe the former is a benefit. as they say, tests should be simples https://github.com/qca/boardfarm/blob/master/README.md#general-guidelines-for-automated-tests | 09:00 |
| Kinnison | I'm fine for tests to be expect driven | 09:01 |
| Kinnison | it's the way it batters around with shells etc in that fashion which upsets me | 09:01 |
| paulsherwood | i'm a little disappointed it's a four-commit dump | 09:02 |
| Kinnison | It's very clearly something which the author uses and has put little effort into making it nice for others to use | 09:02 |
| toscalix_ | Kinnison, agree | 09:03 |
| paulsherwood | Kinnison: actually that's incorrect. from my understanding it's widely used in qualcomm - their board farm is spread across many locations | 09:03 |
| paulsherwood | and iiuc there are many 'users' | 09:03 |
| Kinnison | So the 'author' is Qualcomm in their internal setup | 09:03 |
| paulsherwood | correct | 09:04 |
| Kinnison | I think you misunderstand me | 09:04 |
| paulsherwood | ok | 09:04 |
| Kinnison | It's something the author clearly has put little effort into making it nice for people outside their particular environment to use | 09:04 |
| Kinnison | if that helps | 09:04 |
| paulsherwood | understood, now. | 09:04 |
| Kinnison | This is a very *very* common failing in software which gets "opened up" | 09:05 |
| paulsherwood | ack | 09:05 |
| Kinnison | Not at all surprising | 09:05 |
| * paulsherwood hasn't had time to give it a spin | 09:05 | |
| paulsherwood | i got ybd building on scaleways at the weekend :) | 09:05 |
| paulsherwood | and i got it publishing its artifacts | 09:05 |
| paulsherwood | but this exposed some issues :) | 09:06 |
| *** wschaller has joined #baserock | 09:08 | |
| paulsherwood | so https://github.com/devcurmudgeon/ybd/blob/master/kbas.py is atomic, applying your directory switch idea Kinnison | 09:09 |
| paulsherwood | but i didn't get time to try it with cherrypy or gevent | 09:09 |
| paulsherwood | (to make it non-blocking) | 09:09 |
| *** nowster has quit IRC | 09:47 | |
| *** wschaller has quit IRC | 09:49 | |
| *** wschaller has joined #baserock | 09:55 | |
| *** nowster has joined #baserock | 10:01 | |
| *** straycat_ has left #baserock | 10:17 | |
| *** edcragg has quit IRC | 11:04 | |
| *** edcragg has joined #baserock | 11:05 | |
| *** wschaller has quit IRC | 11:24 | |
| radiofree | paulsherwood: i need to check through the logs again | 11:37 |
| radiofree | however i'm pretty sure both the jetson + mustang generated the same cache key (correct), but their reporting of the cache key didn't match reality | 11:37 |
| radiofree | i'll check next time i have the chance | 11:37 |
| paulsherwood | weird, radiofree. but that log you sent me was consistent | 11:38 |
| *** nowster has quit IRC | 11:39 | |
| *** nowster has joined #baserock | 12:03 | |
| *** wschaller has joined #baserock | 12:15 | |
| *** nowster has quit IRC | 12:35 | |
| *** nowster has joined #baserock | 12:39 | |
| *** petefoth_ has joined #baserock | 12:58 | |
| *** petefoth has quit IRC | 13:00 | |
| *** petefoth_ is now known as petefoth | 13:00 | |
| wdutch | I've made an, admittedly awful, flowchart of how I think the main orchestration of CIAT could behave, I'd appreciate it if somebody could have a look in case I've got the wrong end of the stick. Flowchart: http://i.imgur.com/LiDoKbO.png | 13:07 |
| wdutch | richard_maw pdar Kinnison ^ | 13:07 |
| * paulsherwood notices he's not on wdutch's list, and scowls :) | 13:08 | |
| wdutch | I did not want to bother you | 13:08 |
| paulsherwood | why? lots of folk enjoy bothering me... :) | 13:08 |
| Kinnison | wdutch: that's not quite how I see it | 13:09 |
| Kinnison | wdutch: pretty much everything before "start firehose" is what firehose is | 13:09 |
| * SotK wonders what "start firehose" refers to in that chart. My understanding of the current state of things was that "firehose" was the bit doing the watching and forking. | 13:09 | |
| richard_maw | snap! | 13:09 |
| SotK | heh | 13:09 |
| wdutch | ah okay | 13:10 |
| wdutch | so instead I should be looking for new artifacts appearing? | 13:10 |
| richard_maw | wdutch is not wrong in that it's the flow involved, but we've got pre-existing tooling that we're fitting together, so the boundaries of what we want to do differ | 13:10 |
| Kinnison | aye | 13:10 |
| richard_maw | wdutch: that would be one way to do it, I was assuming we'd have some tool ping the test runner to run tests rather than polling on new artifacts though | 13:11 |
| richard_maw | wdutch: as you don't need to worry about atomically having a set of artifacts available then | 13:12 |
| * SotK would expect something like "start build ---> if successful, start tests ---> if successful, do something (eg vote on a change)!" | 13:13 | |
| * SotK butts out | 13:13 | |
| wdutch | SotK: you make a valid point | 13:13 |
| *** petefoth has quit IRC | 13:15 | |
| wdutch | richard_maw: I don't understand your point on not worrying about atomicness | 13:15 |
| paulsherwood | atomicity :) | 13:15 |
| * Kinnison drew https://awwapp.com/b/uyoktn1vx/ but that possibly doesn't help | 13:15 | |
| *** petefoth has joined #baserock | 13:15 | |
| wdutch | Kinnison: it looks like something from /r/dinosaurdrawings :P | 13:16 |
| Kinnison | You honour me | 13:16 |
| richard_maw | wdutch: unless you only ever have one artifact produced per build, then if you trigger further testing on the presence of an artifact, you might start a test before every artifact it needs has been uploaded | 13:17 |
| wdutch | okay | 13:17 |
| Kinnison | pretty much every operation is a many->many activity | 13:17 |
| richard_maw | wdutch: if you have the service that uploads the artifacts ping the follow up service that it should do something with the new artifacts, then they have all been uploaded before it tries to pick things up | 13:17 |
| Kinnison | many inputs -> activity -> many outputs | 13:18 |
| wdutch | richard_maw: so another component holding the artifacts with a list of what artifacts are needed for a given test which then triggers orchestration? | 13:19 |
| Kinnison | I think that's likely overcomplicating things for now | 13:20 |
| Kinnison | I'd simply have the orchestration watch the artifact cache and when artifacts matching certain patterns turn up, trigger certain activities | 13:21 |
| paulsherwood | +1 | 13:21 |
| Kinnison | e.g. when an artifact matching genivi-demo-platform-test-*.img turns up, trigger the genivi-demo-platform-tests suite | 13:21 |
| wdutch | that just sounds like doing the same thing but giving orchestration an extra job | 13:21 |
| richard_maw | hrm, defined order of upload, and having a different set of trigger files to that of those needed to perform a test would satisfy atomicity | 13:21 |
| Kinnison | orchestration's one and only job is to take input data and trigger behaviours | 13:22 |
| wdutch | okay | 13:22 |
| Kinnison | Otherwise we may as well glue each component directly to the next component in the pipeline and forget about orchestrating anything | 13:22 |
| Kinnison | which, sadly, will open us up to a lot of pain wrt. scaling | 13:22 |
| wdutch | and fungibility | 13:23 |
| Kinnison | indeed | 13:23 |
| nowster | wdutch: how mushroom does it need? | 13:27 |
| paulsherwood | richard_maw: can you expand on your defined order idea? | 13:27 |
| * paulsherwood doesn't understand it yet | 13:27 | |
| * Kinnison reads it as "if a test has multiple inputs then a defined order in which those inputs become available would mean the activity could trigger from the last of those inputs, rather than needing to express some kind of complex dependency" | 13:28 | |
| richard_maw | ^ that | 13:28 |
| paulsherwood | ok | 13:31 |
| *** wschaller has quit IRC | 13:32 | |
| paulsherwood | can someone provide an example of a test requiring multiple inputs? | 13:37 |
| wdutch | why does it need an ordering rather than being a set? | 13:39 |
| richard_maw | paulsherwood: testing that a specific appliance works when run as a container in a specified system, or a multi-system communications test | 13:46 |
| paulsherwood | richard_maw: thanks | 13:47 |
| richard_maw | wdutch: it could be a set of files to watch for if you want to put the complication into the polling logic, rather than the upload logic | 13:47 |
| paulsherwood | richard_maw: for those cases, wouldn't you want to test any new foo with existing versions of other bits, by default? | 13:48 |
| paulsherwood | ie grab new appliance, test with existing container | 13:49 |
| paulsherwood | and same for multi-system, unless flagday | 13:50 |
| richard_maw | it's possibly too early to speculate about that, though I'm nervy about the tests statefully defining the "latest" system | 13:50 |
| paulsherwood | 'latest' is not special. any existing | 13:51 |
| paulsherwood | i didn't say latest | 13:51 |
| wdutch | richard_maw: I don't see how any way other than a set could be sensible, what happens if two artifacts are built in paralell and come out in the wrong order? | 13:54 |
| SotK | wdutch: then the one that should be uploaded second but finished first waits until the one that should be uploaded first finishes I guess | 13:55 |
| richard_maw | paulsherwood: how would you select it from the existing systems then | 13:55 |
| * SotK also prefers the idea of a set rather than relying on ordering though | 13:55 | |
| paulsherwood | richard_maw: doesn't matter much, unless flag day | 13:56 |
| wdutch | SotK: in that case you could end up fork bombing yourself... | 13:56 |
| paulsherwood | richard_maw: in the real world, users have jrandom versio nof system, new thing is hoped to work on all of them | 13:56 |
| * SotK doesn't see how that could cause a fork bomb? | 13:58 | |
| wdutch | you're right, wrong term but you could end up with threads sat around forever | 13:59 |
| richard_maw | paulsherwood: and if it doesn't they may opt to try a new version. I'm even more nervy of selecting something at random than the "latest", since that makes it impossible to make it behave deterministically | 14:00 |
| radiofree | jetson build time for devel system (not including download) 15-08-31 19:26:10 [282/282/282] [TOTAL] Elapsed time 07:03:15 | 14:00 |
| SotK | wdutch: surely you'd just kill them along with the thing they depend on if it doesn't finish? | 14:01 |
| paulsherwood | richard_maw: finding problems is the purpose of this solution | 14:01 |
| *** jonathanmaw__ has joined #baserock | 14:01 | |
| paulsherwood | artificially restricting things will hide issues | 14:01 |
| wdutch | SotK: how do you know when to do that? | 14:01 |
| SotK | same way you do if something hangs and you're uploading stuff in a random order I guess | 14:02 |
| *** jonathanmaw___ has joined #baserock | 14:04 | |
| *** jonathanmaw_ has quit IRC | 14:04 | |
| paulsherwood | richard_maw: note i'm not saying test new-foo against all existing versions, just any. then if there's a problem, git bisect back to last known good | 14:05 |
| *** jonathanmaw__ has quit IRC | 14:06 | |
| *** jonathanmaw___ is now known as jonathanmaw_ | 14:07 | |
| * wdutch thinks having artifacts sat around is much better than having threads hanging | 14:07 | |
| * SotK does too :) | 14:08 | |
| richard_maw | paulsherwood: I see a distinction between "wanting it to work on all versions, and compromising by testing against a possibly randomly selected sample set" and "not caring about which version it is tested with". The former is a deliberate choice, while the latter is an absence of choosing. | 14:10 |
| richard_maw | I'm not sure we're close enough to having something to show that this discussion is useful at the moment. | 14:11 |
| * richard_maw gets back to looking at firehose | 14:11 | |
| *** edcragg has quit IRC | 14:18 | |
| wdutch | am I right in thinking firehose updates definitions but doesn't trigger a build? | 14:28 |
| richard_maw | wdutch: I'm currently investigating that, the original design had it do candidate builds and push the branch if it "built", leaving further testing to later down the pipeline | 14:29 |
| SotK | I think so, I believe the idea when it was last looked at was that it would push the proposed definitions update to Gerrit where Mason would run automated tests on the change. | 14:30 |
| SotK | s/tests/builds and tests/ | 14:31 |
| *** jonathanmaw_ has quit IRC | 15:01 | |
| *** jonathanmaw_ has joined #baserock | 15:13 | |
| *** zoli__ has quit IRC | 15:13 | |
| richard_maw | wdutch, pdar, Kinnison: Ok, so AIUI the latest version of firehose requires a gerrit rather than a regular git repository. If we're going to put together this CIAT prototype using a pre-gerrit Trove, then we need to use a version that's rolled back to before that, and define how the test-builder knows what branches it should test. | 15:29 |
| richard_maw | We can put a hook in the trove to have it ping a service, or the service can poll the definitions repository periodically. | 15:31 |
| * richard_maw double checks how firehose is started | 15:32 | |
| Kinnison | I think the trove should ping an orchestration core (hence wdutch looking at buildbot) | 15:32 |
| Kinnison | firehose as was when I left it was a program to run, not a daemon or service | 15:32 |
| richard_maw | hm, and later versions pretty much just run on a timer | 15:34 |
| paulsherwood | can we use http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure.git/tree/systems/gerrit-system-x86_64.morph | 15:35 |
| paulsherwood | and have gerrit as part of the soln? | 15:35 |
| Kinnison | At some point, yes. But not for now | 15:35 |
| paulsherwood | why go back in time, when fh + gerrit + trove has already been 'done' for a certain value of 'done'? | 15:38 |
| Kinnison | Limited time to understand the pipeline | 15:38 |
| paulsherwood | i'm ok with it, just interested | 15:38 |
| richard_maw | Also, AIUI short-term we're not interested in merging in the candidate branches, which was the purpose of the Gerrit integration. If we were to use the Gerrit'd form, then we'd have to deal with the added complication of fetching the candidate branches from the gerrit, rather than the Trove. | 15:45 |
| Kinnison | It would certainly complicate matters | 15:45 |
| paulsherwood | ack | 15:46 |
| richard_maw | ok, so the orchestrator doesn't need to do anything interesting with firehose, as it can just wait for the process to terminate and pass the resultant candidate branch on to the builder | 15:51 |
| Kinnison | that's a likely approach yes | 15:53 |
| richard_maw | right, so we need to decide whether the orchestrator cares that it was triggered for one branch and resulted in candidate branches from other branches that also happen to have changed, or whether we need to add a mode to firehose to make it only process branches specified on the command-line | 16:00 |
| *** mdunford has quit IRC | 16:19 | |
| *** franred has quit IRC | 16:26 | |
| *** rdale has quit IRC | 16:29 | |
| *** jonathanmaw_ has quit IRC | 16:32 | |
| *** mdunford has joined #baserock | 16:35 | |
| *** mdunford has quit IRC | 17:18 | |
| *** toscalix_ has quit IRC | 18:08 | |
| Walkerdine | Alright now its time to start working on building my own image for the jetson. Turns out I didnt have time to yesterday | 18:24 |
| *** petefoth has quit IRC | 19:34 | |
| *** petefoth has joined #baserock | 19:35 | |
| *** petefoth has quit IRC | 19:47 | |
| *** paulsherwood has quit IRC | 19:50 | |
| *** pdar has quit IRC | 19:50 | |
| *** pdar has joined #baserock | 19:50 | |
| *** paulsherwood has joined #baserock | 19:51 | |
| Walkerdine | Is there an easy way to clone the whole source of the genivi demo platform and to put it on a github | 19:52 |
| *** petefoth has joined #baserock | 19:52 | |
| Walkerdine | Does the cycle.sh script only work on x86 | 20:34 |
| Walkerdine | paulsherwood: do you happen to be around? | 20:37 |
| SotK | Walkerdine: I think cycle.sh should work on ARM too | 20:52 |
| SotK | you'll have to give it `clusters/jetson-upgrade.morph` as the cluster on a Jetson though | 20:53 |
| Walkerdine | I was wondering how to get off of the genivi demo platform once it boots into it | 21:00 |
| Walkerdine | I'm hoping that is the case | 21:00 |
| Walkerdine | I need another monitor | 21:00 |
| *** Walkerdine__ has joined #baserock | 22:08 | |
| *** Walkerdine__ has quit IRC | 23:00 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
