| *** zoli___ has quit IRC | 01:27 | |
| *** zoli__ has joined #baserock | 01:29 | |
| *** zoli__ has joined #baserock | 01:38 | |
| *** paulw has joined #baserock | 06:12 | |
| *** paulw has left #baserock | 06:12 | |
| *** Walkerdine has quit IRC | 07:00 | |
| *** Walkerdine has joined #baserock | 07:12 | |
| *** Walkerdine has quit IRC | 07:15 | |
| *** zoli__ has quit IRC | 07:16 | |
| *** bashrc_ has joined #baserock | 08:01 | |
| pedroalvarez | hey tlsa, your tester scripts need cliapp. Anything else they need? | 08:12 |
|---|---|---|
| tlsa | wdutch: python-novaclient | 08:13 |
| tlsa | pedroalvarez: ^^ | 08:13 |
| wdutch | sorry? | 08:13 |
| *** mariaderidder has joined #baserock | 08:13 | |
| pedroalvarez | and glanceclient I'd guess | 08:13 |
| tlsa | pedroalvarez: yeah, although it just needs the cli tool for that | 08:13 |
| pedroalvarez | cool | 08:14 |
| wdutch | ciat-orchestration depends on virtualenv, sandboxlib and python-request | 08:14 |
| wdutch | ybd doesn't yet run in a virtualenv which is something I'd like to fix | 08:15 |
| tlsa | http://ciat.baserock.org:8010/waterfall <-- looks like it ran out of disc space | 08:15 |
| * wdutch nods | 08:15 | |
| tlsa | http://ciat.baserock.org:8010/json/help <-- looks like we can get various bits of info out of it from there | 08:17 |
| tlsa | any ideas on how to visualise it, or what we want to visulise | 08:18 |
| tlsa | ? | 08:18 |
| wdutch | we're going to make our own webview? | 08:20 |
| tlsa | that's the plan | 08:21 |
| pedroalvarez | My idea: One box per column, green if the latest build was successful, red if not, and yellow but with some "movement" if it's building | 08:21 |
| tlsa | pedroalvarez: that's exactly what the top row of the waterfall shows | 08:22 |
| wdutch | by box you men slave? | 08:22 |
| tlsa | the "last build" row shows that | 08:23 |
| tlsa | except "active" is yellow rather than moving | 08:23 |
| pedroalvarez | wdutch: no, a square | 08:23 |
| pedroalvarez | hehe | 08:23 |
| pedroalvarez | tlsa: also, some lines between boxes representing the triggers | 08:23 |
| pedroalvarez | (that's just my idea) | 08:24 |
| wdutch | yes seeing the flow of the triggers would be useful | 08:24 |
| pedroalvarez | I don't know if you can get that information from the api | 08:25 |
| *** toscalix__ has joined #baserock | 08:28 | |
| *** rdale has joined #baserock | 08:33 | |
| Kinnison | wdutch: Hey, the build on ciat.baserock.org seems broken with ENOSPC again, and afaict it's *still* running in /src rather than /moresrc | 08:34 |
| Kinnison | wdutch: is there a reason it hasn't been moved to the disc 10 times larger than the one it's on? | 08:34 |
| * wdutch patched it to tell ybd to use /moresrc | 08:35 | |
| * wdutch will have a look at what's going on | 08:35 | |
| * Kinnison wonders why it's ENOSPC'ing then | 08:36 | |
| *** jonathanmaw has joined #baserock | 08:39 | |
| wdutch | huh I did a commit to switch back to /src but didn't leave a reason in the commit message | 08:40 |
| wdutch | should I revert it? | 08:41 |
| tlsa | i think it continued to use /src, after pdar added code to delete unpacked system artifacts once they were copied to somewhere else (/archive?) for testing | 08:41 |
| tlsa | but I could be wrong | 08:41 |
| wdutch | this was last friday, it hasn't been a problem in the meantime | 08:42 |
| Kinnison | It ENOSPC'd earlier in the week too | 08:43 |
| pedroalvarez | I think we went back to /src becasue it was faster? or we thought it was? | 08:45 |
| Kinnison | Erm /moresrc is ssd, /archive is spinning rust | 08:45 |
| Kinnison | Though this is all slightly moot in that I could just detach and remove /src and put /moresrc over the top | 08:46 |
| Kinnison | if there's nothing precious in /src | 08:46 |
| pedroalvarez | nothing that cannot be re-created | 08:46 |
| Kinnison | wdutch: would you prefer if I dump /src ? | 08:47 |
| wdutch | I have no preference | 08:47 |
| Kinnison | Choose now | 08:47 |
| wdutch | I don't really know what you mean by 'dump' | 08:49 |
| Kinnison | delete | 08:50 |
| Kinnison | chuck | 08:50 |
| Kinnison | throw away | 08:51 |
| Kinnison | remove | 08:51 |
| Kinnison | erase | 08:51 |
| Kinnison | blast from the face of the earth | 08:51 |
| Kinnison | (terminate the EBS volume) | 08:51 |
| wdutch | and the alternative that I have to choose between is not doing that? | 08:52 |
| wdutch | I don't understand why there must be a preference and why it must be mine | 08:52 |
| wdutch | there's nothing on /src I care about, I have no idea if other people care about it | 08:53 |
| paulsherwood | i want to push a branch to g.b.o. definitions - is that still possible since gerrit? | 08:54 |
| * Kinnison chooses to remove /src | 08:54 | |
| Kinnison | please hold | 08:54 |
| tiagogomes_ | paulsherwood I do it all the time, before realizing that I pushed to the wrong git server | 08:55 |
| paulsherwood | tiagogomes_: origin git://git.baserock.org/baserock/baserock/definitions.git (push) ? | 08:55 |
| Kinnison | wdutch: Okay, the disc behind /src is gone and the disc behind /moresrc is now mounted on /src | 08:55 |
| wdutch | k | 08:56 |
| Kinnison | wdutch: It seems to have some cruft in which might need cleaning up, but I assume (I hope) that things will cope | 08:56 |
| * paulsherwood is getting could not read from remote repo | 08:56 | |
| tiagogomes_ | paulsherwood it needs to be ssh:// to push I believe | 08:56 |
| Kinnison | paulsherwood: You can't push to git:// | 08:56 |
| Kinnison | paulsherwood: (yet) | 08:56 |
| paulsherwood | aha! | 08:56 |
| * Kinnison will be adding support for signed pushes to gitano | 08:56 | |
| Kinnison | and at that point, supporting push to git:// will be possible | 08:56 |
| Kinnison | \o/ | 08:56 |
| pedroalvarez | \o/ | 08:56 |
| pedroalvarez | so, tlsa, did you ever had problems using glanceclient against DC? | 08:57 |
| paulsherwood | tiagogomes_: pls could you provide the full url after the ssh:// ? | 08:58 |
| tiagogomes_ | paulsherwood, ssh://git@git.baserock.org/baserock/baserock/definitions | 08:59 |
| paulsherwood | tiagogomes_: tvm | 08:59 |
| paulsherwood | hmm... maybe i've been revoked for bad behaviour :) | 08:59 |
| tlsa | I need to imporve my understanding of the firehose driven end of the ciat pipeline | 09:00 |
| tiagogomes_ | paulsherwood what is the error? | 09:00 |
| tlsa | does firehose poll the trove for changes? | 09:00 |
| paulsherwood | tiagogomes_: denied | 09:00 |
| paulsherwood | tlsa: i need to improve it too. i can't believe it has to be as complicated as what richard_maw has described | 09:01 |
| tiagogomes_ | paulsherwood I assume that you pushing from a machine containing your ssh key, or you log on the the machine using -A | 09:01 |
| paulsherwood | yup | 09:01 |
| paulsherwood | ah, but there's an error 'ssh: Could not resolve hostname add: nodename nor servname provided, or not known' | 09:02 |
| * paulsherwood thinks this used to work | 09:02 | |
| *** ssam2 has joined #baserock | 09:02 | |
| *** ChanServ sets mode: +v ssam2 | 09:02 | |
| paulsherwood | must be my mac | 09:02 |
| tlsa | what's the recurring scriptbot thing on the left column of http://ciat.baserock.org:8010/waterfall | 09:02 |
| tlsa | wdutch: ^^ | 09:03 |
| wdutch | tlsa: I don't really know, it seems to be an arbitrary name for the sendchange, it came from the example code and I just left it in, it's given by the -W flag which is not documented in the manpage | 09:04 |
| paulsherwood | where is the code for this stuff? | 09:05 |
| paulsherwood | (ciat, i mean) | 09:05 |
| tlsa | wdutch: OK, so does firehose poll the trove for changes? | 09:05 |
| wdutch | paulsherwood: http://cu010-trove.codethink.com/cgi-bin/cgit.cgi/cu010-trove/br6/orchestration.git/ | 09:05 |
| wdutch | tlsa: trove has a hook which sends json to orchestration (bottlerock) which triggers firehose | 09:06 |
| wdutch | paulsherwood: also http://cu010-trove.codethink.com/cgi-bin/cgit.cgi/cu010-trove/br6/buildslave-scripts.git/ for code executed on the slaves | 09:07 |
| tlsa | wdutch: so why are there so many firehose events that don't start a build? Changes in upstream branches that our definitions don't track? | 09:07 |
| wdutch | tlsa: not every change in upstream is relevent | 09:07 |
| wdutch | not every change in upstream will make firehose change definitions and not every change in definitions is a change we care about, I don't know how changes in definitions are evaluated these days, I think all my logic for that has been reverted | 09:09 |
| paulsherwood | wdutch: thanks! | 09:10 |
| Kinnison | tlsa: it's the "blame" indicator | 09:23 |
| Kinnison | tlsa: meant to be so you can see why an operation was triggered IIRC | 09:23 |
| tlsa | ok | 09:24 |
| * wdutch sees no documentation for that but maybe we could make use of it | 09:24 | |
| Kinnison | The JSON calls it 'blame' | 09:26 |
| Kinnison | (I spent some time yesterday reading the JSON) | 09:26 |
| wdutch | cool | 09:27 |
| *** lachlan75 has joined #baserock | 09:48 | |
| ssam2 | initial GNOME system sent for review! | 09:52 |
| ssam2 | https://gerrit.baserock.org/#/c/1134/ | 09:52 |
| ssam2 | it builds, that's about it. But I think we should merge it now and put it in the CI | 09:53 |
| ssam2 | otherwise it will just bitrot again | 09:53 |
| ssam2 | it may actually work under X in fact, it's only been tested with Wayland (which doesn't work for some reason) | 09:54 |
| pedroalvarez | tlsa: so, how did you solve this problem? http://paste.baserock.org/levisufono | 09:54 |
| * pedroalvarez hopes he did | 09:54 | |
| pedroalvarez | I don't get why it would work with one cloud and not with another | 09:55 |
| pedroalvarez | ssam2: "put it in the CI" :) | 09:55 |
| pedroalvarez | I need to automate the cleanups in mason :) | 09:55 |
| paulsherwood | mason will die soon, surely? | 10:00 |
| pedroalvarez | I hope so | 10:03 |
| pedroalvarez | It has been working hard though | 10:03 |
| ssam2 | if it works, I see little reason to kill it, until we have a production quality replacement | 10:04 |
| edcragg | jjardon: why the change to linux-stable for the recent 4.2 update? | 10:04 |
| pedroalvarez | I haven't heard people complaining about long waits for builds for a long time :) | 10:05 |
| pedroalvarez | so, mason has been a success :) | 10:05 |
| edcragg | unless i've missed something, i don't think we want to base our kernels off linux stable | 10:06 |
| pedroalvarez | edcragg: why? | 10:06 |
| edcragg | it's a stable tree, meant for people who for some reason *need* to stick to a particular kernel version for a long time | 10:07 |
| jjardon | ssam2: \o/ | 10:07 |
| jjardon | should I or you vote +1? :) | 10:07 |
| *** toscalix__ has quit IRC | 10:07 | |
| edcragg | pedroalvarez: and why not just stick with mainline? | 10:08 |
| jjardon | edcragg: linux-stable has all the "stable" releases; for example 4.2.1 | 10:08 |
| pedroalvarez | edcragg: I was just asking why, I don't have opinions yet | 10:08 |
| pedroalvarez | we have moved to linux-stable some times | 10:08 |
| edcragg | fair enough | 10:09 |
| edcragg | it does mean that technically it will receive updates it wouldn't from mainline all the while 4.2 is still being used | 10:09 |
| edcragg | which isn't a bad thing | 10:10 |
| *** toscalix__ has joined #baserock | 10:10 | |
| edcragg | although that wouldn't change since baserock is using a SHA as a ref | 10:12 |
| edcragg | so i guess it makes no difference | 10:12 |
| edcragg | (changes to stable branches are hand-picked by a maintainer for each version stable branch, and retroactively applied to the stable branches - for stability and other critical fixes) | 10:15 |
| jjardon | yeah, at some point I would like to track linux-4.2.y instead a fixed sha, but yeah now doesnt make difference | 10:16 |
| edcragg | yeah, makes sense (especially with integration). i still don't see that there's any particular advantage in basing it off a stable branch, particularly, though | 10:17 |
| *** lachlan75 has quit IRC | 10:18 | |
| pedroalvarez | jjardon: I hope that CIAT will do that for us (track a branch, change the sha1, test the change, and send the patch for review) | 10:20 |
| pedroalvarez | same for gnome ;) | 10:20 |
| jjardon | I hope it can handle it :) this is a first iteration of the GNOME system, and still some bug components are missing (like webkitgtk) | 10:22 |
| *** Lachlan1975 has joined #baserock | 10:24 | |
| ssam2 | *big | 10:24 |
| ssam2 | I guess we can both +1 but neither of us should +2 | 10:24 |
| ssam2 | maybe that is fair | 10:24 |
| Kinnison | wdutch: orchestration on ciat seems to believe its address is 0.0.0.0 -- can you teach it to believe that it is ciat.baserock.org instead? | 10:24 |
| Kinnison | wdutch: otherwise the URLs in the JSON output are broken | 10:24 |
| wdutch | okay | 10:24 |
| pedroalvarez | and port 80 :) | 10:24 |
| pedroalvarez | or not | 10:24 |
| pedroalvarez | nevermind | 10:24 |
| pedroalvarez | we better put something nicer in port 80 | 10:25 |
| wdutch | may I take it offline briefly? | 10:25 |
| pedroalvarez | we should assume that it is going to be an intermitent service | 10:26 |
| Kinnison | No, I'm going to put other stuff on port 80 | 10:27 |
| ssam2 | the announcement email Daniel didn't actually *say* that it was a prototype and shouldn't be relied upon for important work yet, but I kind of assumed that it still is | 10:28 |
| pdar | is there a convention of what ports to put things on? | 10:29 |
| richard_maw | http is 80, 80XY is usually used for testing web services | 10:30 |
| *** zoli__ has joined #baserock | 10:30 | |
| richard_maw | see /etc/services | 10:30 |
| wdutch | pdar: if you're interested in general:http://overapi.com/static/cs/common_ports.pdf | 10:30 |
| pdar | and what happened to moresrc? | 10:30 |
| pdar | thanks richard_maw wdutch | 10:31 |
| pdar | whoops, it seems I put the image server test thing on the internet radio port | 10:32 |
| pedroalvarez | are you listening your favourite images? | 10:33 |
| *** gary_perkins has quit IRC | 10:34 | |
| *** toscalix_ has joined #baserock | 10:34 | |
| pedroalvarez | tlsa: yay, the problem with deploying to DC is because an eventlet bug. | 10:35 |
| pedroalvarez | I should upgrade the eventlet version of baserock to 0.17.4 | 10:35 |
| * pedroalvarez makes a note | 10:35 | |
| pdar | has src breen replaced with moresrc on the ciat? | 10:37 |
| *** toscalix__ has quit IRC | 10:38 | |
| *** gary_perkins has joined #baserock | 10:39 | |
| wdutch | pdar: I believe that Kinnison did that, yes | 10:39 |
| pdar | wdutch: okay, ta i shall put the cache archive thing elsewhere then | 10:40 |
| pdar | are we alowed to play with the master buildslave scripts again? | 10:42 |
| Kinnison | pdar: Put it in /src, but ideally in a subdir somewhere | 10:42 |
| Kinnison | :-) | 10:42 |
| pdar | Kinnison: okeydokey | 10:43 |
| * wdutch has problems replacing 0.0.0.0 with ciat.baserock.org, ciat may be down a bit longer | 10:44 | |
| Kinnison | wdutch: if it wants it to be an A record not a CNAME then use ciat-aws-0.baserock.org | 10:48 |
| wdutch | looks to be working http://ciat.baserock.org:8010/waterfall | 10:52 |
| wdutch | bottle didn't like it though | 10:52 |
| Kinnison | bottle is after a bind address so 0.0.0.0 is fine for that | 10:52 |
| Kinnison | the buildbot needs a proper address to tell others | 10:52 |
| wdutch | okeedoke | 10:52 |
| *** toscalix_ has quit IRC | 10:52 | |
| *** toscalix_ has joined #baserock | 10:52 | |
| Kinnison | though the json still says 0.0.0.0 | 10:52 |
| Kinnison | gah | 10:52 |
| Kinnison | consider http://ciat.baserock.org:8010/json/builders/1.%20Integration/builds/_all?as_text=1 | 10:53 |
| Kinnison | see the log URLs near the top? | 10:53 |
| *** CTtpollard has joined #baserock | 10:53 | |
| CTtpollard | What is the genivi system baserock is building with the new CIAT? | 10:54 |
| pedroalvarez | CTtpollard: GDP | 10:55 |
| pedroalvarez | from an old branch that jonathanmaw had around I believe | 10:56 |
| Kinnison | CTtpollard: genivi-demo-platform-x86_64-generic | 10:56 |
| CTtpollard | very nice | 10:56 |
| pedroalvarez | i'm currently thinking that maybe the network-id to use in the ciat testing belongs more to the o hosts configuration than to the systems configuration | 10:59 |
| pedroalvarez | but the flavours... meh | 11:00 |
| Kinnison | mmm flavours | 11:00 |
| paulsherwood | i'm about to forward kinnison's email to a lot of folks... can i assume the ciat url will remain reasonably solid? | 11:01 |
| *** toscalix_ has quit IRC | 11:02 | |
| Kinnison | Yes, if you want | 11:04 |
| paulsherwood | :-) | 11:04 |
| Kinnison | I arranged the DNS so that when we migrate the work to a different system, we can flip the CNAME trivially | 11:05 |
| paulsherwood | Kinnison: i assume you don't object to the forwarding? i think my cover email will be less entertaining, but more disruptive | 11:05 |
| Kinnison | paulsherwood: my only concern is that it points at the known-pants UI rather than the nicer one we hope to create in the coming week if we can find time | 11:05 |
| paulsherwood | sure | 11:06 |
| Kinnison | paulsherwood: If you're okay with the pig going out sans-lippy then forward it | 11:06 |
| paulsherwood | i'm ok with it | 11:06 |
| * Kinnison wonders who paulsherwood intends to disrupt :-) | 11:07 | |
| paulsherwood | :-) | 11:07 |
| pedroalvarez | oh! finally spotted the problem with `nova boot` | 11:17 |
| pedroalvarez | - '--nic', 'net-id', self.net_id, | 11:18 |
| pedroalvarez | + '--nic', 'net-id=' + self.net_id, | 11:18 |
| Kinnison | pedroalvarez: yay | 11:19 |
| paulsherwood | what about using meeor for the ciat ui? | 11:19 |
| paulsherwood | that + colour + rectangles with rounded corners == shiny. | 11:20 |
| wdutch | paulsherwood: the advantage would be the reactivity | 11:20 |
| paulsherwood | wdutch: plus it's fast to hack in, iirc? | 11:20 |
| wdutch | the main disadvantage of meteor would be the database | 11:20 |
| wdutch | I din't know if they support sqlite | 11:20 |
| Kinnison | meteor seems to be entirely pointless | 11:20 |
| Kinnison | for what we need | 11:20 |
| Kinnison | which is consuming some semi-static data and then a JSON API | 11:21 |
| Kinnison | to render data | 11:21 |
| paulsherwood | we just need shiny :) | 11:21 |
| wdutch | it's fast to hack in if you are comfortable with javascript, which a lot of people here are not :P | 11:21 |
| paulsherwood | Kinnison: and in other conversations you've admitted you are the wrong person to talk about graphical ui :-) | 11:21 |
| wdutch | maybe CTtpollard has an opinion, he knows meteor O:) | 11:21 |
| paulsherwood | CTtpollard: cmon, say yes! | 11:22 |
| Kinnison | paulsherwood: I'm not the wrong person for frameworks though | 11:22 |
| Kinnison | paulsherwood: I just dislike the shiny | 11:22 |
| pedroalvarez | he can say yes if he is going to do it :) | 11:22 |
| CTtpollard | ..... | 11:22 |
| paulsherwood | maybe i should do it myself :-) | 11:22 |
| pedroalvarez | +1 | 11:22 |
| pedroalvarez | :{P | 11:22 |
| paulsherwood | i'm pretty busy next week, though | 11:23 |
| ssam2 | is the JSON API going to be exposed as well? | 11:23 |
| Kinnison | It already is | 11:23 |
| ssam2 | so there could theoretically be multiple UIs ? | 11:23 |
| paulsherwood | yup | 11:23 |
| Kinnison | ssam2: indeed | 11:23 |
| ssam2 | (not that it's a good idea to try to do 2 for next week, just curious) | 11:23 |
| * wdutch is reminded of http://www.commitstrip.com/en/2015/09/16/how-to-choose-the-right-javascript-framework/ | 11:23 | |
| Kinnison | ssam2: http://ciat.baserock.org:8010/json/help | 11:23 |
| ssam2 | ah, cool | 11:24 |
| Kinnison | ssam2: The lipstick for the pig would be something consuming a description of the pipeline (which we could generate as we generate the buildbot and firehose configs) and consuming that JSON API in some fashion | 11:24 |
| ssam2 | so it'd kind of visualise the pipeline, and show status? | 11:25 |
| Kinnison | ssam2: at least initially yes | 11:25 |
| ssam2 | this sort of thing is tricky, I've not actually seen a UI that I like for a CI tool, ever | 11:25 |
| Kinnison | ssam2: eventually it could also consume descriptions of the elastic resources etc | 11:25 |
| Kinnison | ssam2: and show things like the build/test farm size and direction of growth/shrinkage | 11:25 |
| Kinnison | ssam2: etc. | 11:25 |
| ssam2 | actually http://build.gnome.org/ is quite nice, but probably because it's so simple. CIAT couldn't really be so simple | 11:25 |
| paulsherwood | yup. i was hoping we could use concourse, but from my initial explore there it's way more code/complexity than i expected | 11:26 |
| Kinnison | ssam2: a white page with a list of builds down the left | 11:26 |
| Kinnison | paulsherwood: concourse is an entire CI system afaict | 11:26 |
| paulsherwood | yup | 11:27 |
| ssam2 | Kinnison: it used to show the test results in a more fancy way :-) | 11:27 |
| paulsherwood | and it's dockertastic | 11:27 |
| rjek | Is there a guide to how to interpret the waterfall page? I find it quite confusing | 11:27 |
| Kinnison | paulsherwood: and there's a strong reason not to use it | 11:27 |
| paulsherwood | yup | 11:27 |
| Kinnison | rjek: that the waterfall page is confusing is exactly why we're trying to re-skin things | 11:27 |
| rjek | Ah | 11:27 |
| * rjek will be quiet, then | 11:27 | |
| ssam2 | but actually, once it goes beyond a list of builds, it becomes really confusing to me, always. Maybe there's a clever way to make more complex systems easily comprehensible, but I've not seen one yet | 11:27 |
| rjek | Enjoy it while it lasts | 11:27 |
| Kinnison | rjek: in brief, the columns are the pipeline stages, (kinds of work to do) the vertical axis is time, and there's no visualised linkage for triggers | 11:28 |
| ssam2 | but since there is an API exposed, we enable research in this area :-) | 11:28 |
| Kinnison | ssam2: :-) | 11:29 |
| SotK | Is there a common opinion (however vague) on what the shiny UI should have in it? | 11:30 |
| rjek | Mirrors. | 11:31 |
| Kinnison | SotK: Currently the person with the strongest vision on what shiny we need is paulsherwood | 11:31 |
| Kinnison | SotK: I am the person with the weakest vision wrt. the UI and possibly the strongest opinions wrt. the backend complexity | 11:31 |
| wdutch | does ybd record which artefacts it produced when it builds a system? | 11:35 |
| Kinnison | I think pdar was working on something to do that | 11:35 |
| wdutch | having CIAT keep track of which systems are built in order to trigger deploys of clusters depending on multiple systems will depend on the artefacts not being removed, is this okay for now or too hacky? | 11:36 |
| wdutch | then again a deploy will just build them again ... | 11:37 |
| wdutch | or try to | 11:37 |
| Kinnison | I'm fine if for now we assume things just built won't be thrown away | 11:39 |
| Kinnison | later we can consider ways to manage locking to ensure things | 11:39 |
| pedroalvarez | tlsa: can you explain to me the TODO of the line 236? | 11:42 |
| pdar | wdutch: regards 12:35. It doesnt, I have a branch that can do that if you need it | 11:46 |
| wdutch | pdar: awesome, I'll spin up a test server and we'll give it a go, I need some lunch first though, I'll ping you in a bit :) | 11:47 |
| *** CTtpollard has quit IRC | 11:56 | |
| *** tiagogomes_ has quit IRC | 11:59 | |
| *** tiagogomes_ has joined #baserock | 11:59 | |
| pedroalvarez | I just had a weird backtrace when pushing to the trove that ciat is using | 12:05 |
| pedroalvarez | http://paste.baserock.org/manoxayana | 12:05 |
| paulsherwood | i've pushed back on pdar's change so far.. https://github.com/devcurmudgeon/ybd/pull/124 | 12:15 |
| paulsherwood | am i missing something? wouldn't this be best in the meta file? | 12:16 |
| paulsherwood | wdutch: ^^ | 12:16 |
| Kinnison | The big issue is that we need to know, for a given run of ybd, the exact cache key of the system built | 12:17 |
| straycat | for ui, maybe worth looking at http://hydra.nixos.org/project/nixos#tabs-project for inspiration? pretty similar system? | 12:18 |
| *** straycat is now known as sleepycat | 12:21 | |
| Kinnison | So I like that, but I fear paulsherwood will think it doesn't match his vision | 12:22 |
| wdutch | unless I'm missing something it's just lists which doen't do any of the work of helping you visualise it | 12:27 |
| tlsa | pedroalvarez: I don't have a todo on that line | 12:31 |
| tlsa | have you pulled the last version I pushed? | 12:31 |
| tlsa | pedroalvarez: or just paste the full comment here? | 12:31 |
| wdutch | pdar: paulsherwood: The metafile where where I looked when wondering if it kept track of the system. It would make sense to me | 12:31 |
| *** sleepycat is now known as tiredcat | 12:43 | |
| paulsherwood | Kinnison: that's in the log from ybd? | 12:46 |
| Kinnison | paulsherwood: I'd far prefer a proper interface rather than loggrepping | 12:47 |
| paulsherwood | Kinnison: interface how? where? | 12:48 |
| * Kinnison wants a tool which answers the question "Given these definitions, what is the cachekey for this thing" | 12:48 | |
| Kinnison | But failing that, having ybd be able to be explicitly told "Write out the cache keys of what you build to here" would do | 12:48 |
| paulsherwood | ok i understand | 12:48 |
| Kinnison | My eventual goal is a suite of smaller tools (smaller even than ybd) which cover the use-cases | 12:49 |
| paulsherwood | i think the nixos approach is simple and sensible. i have a short term interest to see something shiny since we're off to ELCE with it, that's all | 12:49 |
| paulsherwood | Kinnison: ybd is already useable as a library | 12:50 |
| paulsherwood | so tool could parse definitions and ask cache_key(target) | 12:50 |
| Kinnison | paulsherwood: if you can give pdar some hints as to how he might achieve that, that'd be great | 12:51 |
| Kinnison | paulsherwood: or even knock up a tiny tool for it yourself if you think it's trivial | 12:51 |
| * Kinnison doesn't have the brainspace to try and grok ybd's "library" | 12:51 | |
| paulsherwood | ssam2: could you explain the approach? | 12:52 |
| ssam2 | this is as far as I got with using YBD as a library: https://github.com/CodethinkLabs/research-git-active-days/blob/master/measure.py | 12:58 |
| ssam2 | you can get a ybd.Definitions() instance, which lets you do a couple of things, including get the results of YBD's cache key calculation I think | 12:58 |
| ssam2 | hmm that example just uses the ybd.repos module, not the cache keys | 12:59 |
| paulsherwood | i guess it's noisy (outputs all the cache-keys while parsing defintions) | 12:59 |
| Kinnison | I don't care about noise | 12:59 |
| Kinnison | logging can be shuffled elsewhere | 12:59 |
| paulsherwood | ybd.cache.cache_key(system) would be the magic call after following same setup as ssam2's measure.py | 12:59 |
| ssam2 | yeah, that should work | 13:00 |
| ssam2 | where you can find system with Definitions.get('systems/foo.morph') I think | 13:00 |
| *** bashrc_ is now known as bashrc | 13:03 | |
| bashrc | does baserock have a definition for lttng ? | 13:04 |
| Kinnison | I don't believe we currently include that anywhere, no | 13:05 |
| bashrc | ok, was just wondering | 13:06 |
| bashrc | having a good tracing system might be useful for embedded | 13:06 |
| richard_maw | is lttng one of those that require non-mainline kernel patches? | 13:10 |
| richard_maw | 'cause there's already upstreamed tracing tools AIUI | 13:10 |
| bashrc | which are those? | 13:15 |
| * richard_maw can't remember the names | 13:15 | |
| richard_maw | but there's talk of traces being {e,}BPF filters | 13:16 |
| Kinnison | there's things like ftrace | 13:16 |
| bashrc | yes, ftrace is built in | 13:16 |
| bashrc | but afaik is kernel specific, not a general tracing system | 13:17 |
| * richard_maw vaguely remembers talk of one of the kernel tracing things being extended to userland | 13:18 | |
| *** petefoth has quit IRC | 13:20 | |
| pedroalvarez | tlsa: I was refering to this chunk of code: http://paste.baserock.org/ruwesoxidu | 13:31 |
| Kinnison | richard_maw: I think it's perf | 13:31 |
| tlsa | pedroalvarez: looks redundant | 13:34 |
| tlsa | (the TODO) | 13:34 |
| pedroalvarez | ok, it's working anyway :) | 13:35 |
| tlsa | really? the whole thing works? | 13:35 |
| * tlsa is amazed | 13:35 | |
| pedroalvarez | well, it fetched the images, created them, and then created the instances and waited for ssh | 13:36 |
| pedroalvarez | given that they were 0byte images, nothing else happened :P | 13:36 |
| radiofree | why does gerrit need flash | 13:39 |
| radiofree | never mind, "copy to the clipboard" | 13:40 |
| paulsherwood | thinking about this need for cache_key(system).... is the deploy step being given a completely new checkout, or using the same one as the build? | 13:48 |
| pedroalvarez | paulsherwood: I would assume a new checkout. It may happen in a different machine | 13:49 |
| paulsherwood | ok | 13:49 |
| *** jonathanmaw has quit IRC | 13:49 | |
| pedroalvarez | I may be wrong, though | 13:49 |
| paulsherwood | you're probably right | 13:50 |
| tlsa | pedroalvarez: still, it's got further than I could have hoped, given it was hastily thrown together and untested when I handed it over :) | 13:51 |
| pedroalvarez | well, I found a couple of tiny bugs :) | 13:52 |
| pedroalvarez | testing now with a real image | 13:53 |
| tlsa | pedroalvarez: ah, ok :) | 13:53 |
| tlsa | the image you deploy needs to have an authorized_keys with the public key from the system/user running the test runner | 13:54 |
| paulsherwood | pdar: i've merged your cache-log chang | 13:54 |
| pedroalvarez | tlsa: oops, good to know | 13:54 |
| * pedroalvarez ^Cs | 13:54 | |
| *** jonathanmaw has joined #baserock | 13:56 | |
| pdar | paulsherwood: cool, thanks paul! | 13:56 |
| paulsherwood | np... it's a workable solution - if i think if something better we can improve later | 14:03 |
| paulsherwood | which was the systemdd patch that required a fix in definitions? can someone provide links please? | 14:14 |
| pedroalvarez | yup, one sec | 14:15 |
| pedroalvarez | paulsherwood: http://git.baserock.org/cgi-bin/cgit.cgi/delta/systemd.git/commit/?id=d379d44255469f03994832ab5821bf1b9034f4dc | 14:16 |
| *** zoli__ has quit IRC | 14:22 | |
| paulsherwood | pedroalvarez: tvm | 14:23 |
| paulsherwood | and the problem was what precisely, in one line? | 14:23 |
| pedroalvarez | systemd requred a new version of util-linux | 14:24 |
| pedroalvarez | newer version of util-linux triggered a problem in our integration of readline | 14:26 |
| pedroalvarez | so there were 2 changes in definitions: fix readline, and upgrade util-linux | 14:26 |
| paulsherwood | tvm | 14:26 |
| paulsherwood | now... it just occurs to me ... is that new version or readline GPLv3? | 14:27 |
| paulsherwood | s/or/of/ | 14:27 |
| pedroalvarez | paulsherwood: no no, I didn't upgrade readline, I fixed the integration | 14:28 |
| paulsherwood | aha :) | 14:28 |
| paulsherwood | tvm | 14:28 |
| pedroalvarez | I'm aware of the readline and GPLv3 problem :) | 14:28 |
| pedroalvarez | anytime :) | 14:28 |
| *** franred has joined #baserock | 14:31 | |
| pedroalvarez | tlsa: testing images work :) I've added a warning when the tester tries to test in systems that weren't defined | 14:49 |
| pedroalvarez | tlsa: I'll try to make it show the output of the tests | 14:50 |
| tlsa | cool | 15:03 |
| pedroalvarez | :) | 15:03 |
| tlsa | stdout=self.output | 15:04 |
| tlsa | add that to the runcmd call? | 15:04 |
| pedroalvarez | yup, I was going to try that | 15:04 |
| pedroalvarez | I wonder why we are not using cliapp.ssh_runcmd (or however it's called) | 15:06 |
| richard_maw | pedroalvarez: insufficient support for temporary auth options | 15:06 |
| pedroalvarez | aha! makes sense | 15:07 |
| *** zoli__ has joined #baserock | 15:16 | |
| pedroalvarez | yay! output! | 15:26 |
| tlsa | \o/ | 15:27 |
| pedroalvarez | things left: run commands as a given user (should be easy) | 15:27 |
| pedroalvarez | and proper clean ups | 15:27 |
| tlsa | did you need to change much to get it going? | 15:28 |
| pedroalvarez | nope | 15:29 |
| tlsa | cool | 15:29 |
| *** fay_ has quit IRC | 15:38 | |
| pedroalvarez | not sure if I should redirect stderr too. I'll leave it as it is for now | 15:43 |
| *** rdale has quit IRC | 15:52 | |
| *** fay_ has joined #baserock | 16:24 | |
| *** mariaderidder has quit IRC | 16:31 | |
| tlsa | pedro: The only way to run it without the output order messing up when the output is captured as a log is to run it with `python -u tester` | 16:36 |
| tlsa | cos stdout gets buffered and stderr doesn't unless you force it to run unbuffered like that | 16:37 |
| *** fay_ has quit IRC | 16:39 | |
| *** ssam2 has quit IRC | 16:45 | |
| pedroalvarez | tlsa: aha, thanks for the info! | 16:51 |
| * jjardon goes to celebrate that the first chunk of the GNOME system has been integrated in definitions :) | 16:53 | |
| pedroalvarez | right, if redirect the output to a file then the output is messed up :) | 16:54 |
| * pedroalvarez tries `python -u` | 16:54 | |
| pedroalvarez | hm.. that didn't solve the problem | 16:56 |
| pedroalvarez | I'll forget about this for now | 16:56 |
| *** bashrc has quit IRC | 16:57 | |
| *** jonathanmaw has quit IRC | 17:00 | |
| *** petefoth has joined #baserock | 17:00 | |
| *** fay_ has joined #baserock | 17:16 | |
| *** fay_ has quit IRC | 17:18 | |
| *** franred has quit IRC | 17:26 | |
| *** tiagogomes_ has quit IRC | 17:59 | |
| *** Lachlan1975 has quit IRC | 18:28 | |
| *** zoli__ has quit IRC | 20:26 | |
| *** zoli__ has joined #baserock | 20:35 | |
| *** zoli__ has quit IRC | 21:05 | |
| *** zoli__ has joined #baserock | 21:17 | |
| *** zoli__ has quit IRC | 22:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!