IRC logs for #baserock for Thursday, 2014-10-23

*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]00:08
*** zoli_ [] has joined #baserock04:13
*** zoli_ [] has quit [Changing host]04:13
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock04:13
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]04:36
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock04:37
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 265 seconds]04:41
*** circ-user-HhgcW [~circuser-@2601:9:7680:971:744f:cd36:351b:c653] has joined #baserock06:09
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-foiupxvydubaayvx] has quit [Ping timeout: 260 seconds]06:09
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-hhzujylmdusfoekc] has joined #baserock06:10
*** sam_ [] has joined #baserock06:11
*** sambishop [] has quit [Ping timeout: 272 seconds]06:12
*** circ-user-HhgcW [~circuser-@2601:9:7680:971:744f:cd36:351b:c653] has quit [Ping timeout: 265 seconds]06:32
*** dutch [] has joined #baserock07:11
*** tiagogomes [~tiagogome@] has joined #baserock07:34
pedroalvarezOk, I will merge it then doing that change07:39
pedroalvarezrichard_maw: btw, thank you for doing a yarn for system-integration commands07:39
pedroalvarezugh... one needs around 6G of free space to run the morph test sute07:57
*** jonathanmaw [] has joined #baserock08:16
pedroalvarezI wonder what PYTHONPATH i have to use to run the lorry-controller test suite08:19
pedroalvarezI see... it needs some python libraries to run08:23
pedroalvareze.g. boottle08:23
KinnisonAye, bottle, likely flup08:28
pedroalvarezthey work in a trove :)08:30
*** rdale [] has joined #baserock08:32
*** ssam2 [] has joined #baserock08:37
Mode #baserock +v ssam2 by ChanServ08:37
*** rdale [] has quit [Ping timeout: 255 seconds]08:45
*** rdale [] has joined #baserock08:45
*** Krin [] has joined #baserock09:00
*** rdale [] has quit [Ping timeout: 265 seconds]09:03
*** rdale [] has joined #baserock09:03
ssam2it's often an education reading richard_maw's patches... today I learned about the Python 'textwrap' module09:05
rjekI thought python had a module for everything :)09:06
straycatssam2, Indeed I didn't realise you could do partial application in python, nor did I know about asyncore09:07
Krinrjek, python even has a module for python :)09:08
franredrjek, s/a module/multiple modules/09:08
*** rdale [] has quit [Read error: Connection reset by peer]09:09
*** rdale [] has joined #baserock09:09
richard_mawthere's a reason why the section in called "Library Reference" has the subtitle _keep this under your pillow_09:14
* rjek keeps another pillow under his pillow.09:15
*** rdale [] has quit [Ping timeout: 244 seconds]09:16
*** rdale [] has joined #baserock09:16
* richard_maw keeps two half pillows under his pillow, so he has neck support from the other halves if he rolls in his sleep, and can get away with 3 pillows rather than 409:17
pedroalvarezI put my arm under my pillow :)09:18
* persia always worries about cracking the PCB when doing that09:19
rjekYeah, my arm is normally sandwiched between the two pillows.09:19
pedroalvarezpersia: pcb?09:19
rjekwhat else are you meant to do with arms when in bed, anyway?09:20
persiapedroalvarez: The printed circuit board on which my ARM is mounted09:20
rjekpersia: Do you wear SoCs in bed?09:21
rjekI'll get my coat.09:21
persiarjek: No, I specifically don't tend to put them under my pillow because of fear of breaking them09:21
richard_mawnow, who's going to make a raspberry pi joke?09:21
franredrichard_maw, no hungry at the moment, I already have breakfast09:23
*** jonathanmaw [] has quit [Ping timeout: 256 seconds]09:35
*** jonathanmaw [] has joined #baserock09:39's IO appears to be saturated10:08
ssam2lots of 'cvsps' processes in 'top'10:08
ssam2I don't know if this is normal or if something is wrong10:08
richard_mawcvs import most likely10:08
* pedroalvarez thinks we should increase the lorries interval10:10
ssam2yeah, nothing overly worrying to me in the journal10:10
ssam2pedroalvarez: that sounds like it might be a good plan10:11
Kinnisonpedroalvarez: We need to work out a way to horizontally scale lorry10:11
pedroalvarezKinnison: what do you mean?10:11
Kinnisonpedroalvarez: something like NFS-sharing the /home/lorry between multiple cloud instances, and having minions on several systems10:11
pedroalvarezthat would be great10:12
pedroalvarezso the lorry-controller has workers, and every worker lorry things with one or multiple minions, and they push things to a git server10:13
pedroalvarezwhich can be gitano, gerrit, or gitlab10:13
pedroalvarezor whatever10:13
Kinnisonlorry controller has minions10:13
KinnisonI believe thouse could, in theory, be on different systems without issue10:13
persiaFor horizontal scaling, can we do something like separate workers and a dispatch system?10:22
* persia doesn't quite understand why /home/lorry needs be shared10:23
Kinnisonthe working area for lorry needs to be shared, or else lorries need to be tied to minions10:26
KinnisonSome conversions are strictly reliant on the stability of their working area10:26
persiaAh, so a given lorry needs to have the leftovers from the previous run to run smoothly?10:27
persiaHmm.  That makes it harder.  Storing separate lorry working areas in separate shares gets annoying quickly.10:29
richard_mawpedroalvarez: do you recall why you used chroot rather than linux-user-chroot for the system-integration commands?10:31
pedroalvarezI remember I tried to reuse the existing code used to build chunks10:33
pedroalvarezI also remember I tried to use linux-user-chroot, but i can't remember why I finally used chroot10:34
ssam2neither the commit logs nor the code seem to mention why ... bad Pedro !10:35
Kinnisonpersia: I was thinking either NFS private to the cluster, or perhaps ceph10:39
persiaDoes Ceph file store work reliably yet?  I know the block store is in good shape10:40
Krinhi i have spotted a bug in my endless bumbling through baserock, it seems kvm.check is not validating that the target path is writeable when doing a deploy,10:42
* straycat nods10:43
straycatThe validation in the kvm ext is generally not that great10:43
pedroalvarezgiven the flexivbility of the write and check extensions, it would be possible to add10:43
richard_mawpedroalvarez: I prefer that spelling, more stuff needs v in the middle of it10:44
* straycat thought richard_maw would prever it10:44
Kinnisonpersia: no idea, hence ", or perhaps ceph"10:44
persiaBut yeah, if we need that, then a shared network filestore seems the sensible model.  If there was a way not to need that, it would be nice, but that's harder.10:45
KinnisonBasically to not need it would either need us to package up and move around these work areas on demand, or else to lock given lorries to given minions10:46
Kinnisonthe former is extra resource consumption, the latter is potential bottlenecks10:46
persiaThe latter also reintroduces SPF issues.10:47
KinnisonAye, SPoF is a pain10:47
persiaWhich means either packaging it up, or some scalable namespace that can be used to address individual filestores.10:47
persiaEIther of which requires extra resources: compute in the first case, and storage and system complexity in the second10:48
KinnisonWhich leads back to NFS-share (which is backed up) being the least-cost initial implementation to see if it helps to have more minions10:52
pedroalvarezAnyway, I think we could start decoupling the lorry controller from the git server. 10:59
KinnisonI think that'd be quite easy frankly10:59
Kinnisongiven it interacts entirely over ssh10:59
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock11:11
pedroalvarezhm.. instructions about how to configure a generic trove have been removed from the wiki :(11:15
pedroalvarezalso, I don't understand why the instructions now to deploy a trove to openstack suggest you to use an "ephimeral" disk11:16
pedroalvarezit should use a volume11:17
persiaYes, and if it wants to use something else, it should probably spell it ephemeral11:17
pedroalvarezoh, that was me11:18
pedroalvarez"efimero" in spanish11:18
persiaheh.  Silly insistance an orthography that maps directly to pronunciation11:19
pedroalvarezyeah, but this way is easier to learn to speak english, although not to write it properly as you can see11:21
persiaIndeed :)11:23
* straycat reduced the docs to make it quicker to get going with trove11:28
straycatI suggested using an ephemeral because that's simpler11:30
pedroalvarezI agree now is easier to read, and the example is simpler11:35
persiaI suspect sticking with ephemeral for "trove" makes sense.  As we deconstruct it into constituent parts, we can pick the best solution for each.11:37
persiaFor example, the git server probably wants a volume, so the volume can be snapshotted and backed up independently from the git server, etc.11:38
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]13:38
*** rdale_ [] has joined #baserock14:16
*** rdale [] has quit [Read error: Connection reset by peer]14:16
jjardonrdale_: as far as I understand -qt-xcb is only needed to use some internal libraries instead the ones in the system: this is not needed for us as we have all the xcb stuff in x-common14:20
rdale_yes, i agree14:20
rdale_so i need to ask radiofree why he used that option14:21
jjardonand the xserver in x-generic14:21
radiofreerdale_: that stratum is from when i was making a wayland only system14:29
radiofreeand probably the x strata weren't so well defined14:29
*** dabukalam [] has joined #baserock14:29
radiofreeprobably safe to not use that now if you build depend on x-common14:29
rdale_if it doesn't find any x libs, it just won't build the xcb plugin, so i think we can just do away with the -qt-xcb option 14:30
radiofreeif you're sure about that then go ahead and leave it out14:30
radiofreei remember having to add that because it failed14:31
rdale_my jetson, just seems to have died on me now. once i get it going again i'll try building without the flag. it fails with the flag unfortunately atm14:31
radiofreerdale_: how did it die?!14:32
radiofreekernel panic?14:32
radiofreeyou're a test case for that kernel that i'd like to send a patch to use everywhere14:32
rdale_the serial port connection and ssh connections got less and less reponsive, although the hdmi seemed ok14:33
rdale_now i've tried to reboot and it's stuck14:33
radiofreestuck where?14:33
rdale_'Retrieving file: /systems/default/dtb'14:34
rdale_in u-boot14:34
radiofreedid you do a cycle on it?14:35
radiofree(before rebooting)14:35
rdale_i just unplugged it14:35
radiofreereboot an interupt u-boot, is there a "ums" command there?14:35
radiofreedo a btrls mmc 014:36
radiofreethen sysboot mmc 0 btrfs 0x90000000 extlinux.conf14:36
rdale_<DIR>       systems14:36
rdale_<DIR>       state14:36
rdale_<FILE>      extlinux.conf14:36
rdale_i should boot off the sd card?14:37
radiofreemmc 0 is the emmc14:37
rdale_ah ok14:37
rdale_that's doing something now14:37
radiofreeit's booting?14:38
rdale_it has booted ok14:38
radiofreethese btrfs patches are a bit... sensitive14:38
rdale_i'll try building without -qt-xcb now and see what happens14:39
rdale_for a wayland only system, i think '-no-xcb-xlib' might be best14:48
*** dabukalam [] has quit [Quit: Leaving]15:02
*** jjardon [sid723@gateway/web/] has quit []15:27
*** jjardon [] has joined #baserock15:29
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 265 seconds]15:54
*** dutch [] has quit [Quit: Quit]16:10
*** jonathanmaw [] has quit [Quit: Leaving]16:18
*** ssam2 [] has quit [Ping timeout: 246 seconds]16:50
*** genii [~quassel@ubuntu/member/genii] has joined #baserock17:08
*** Krin [] has quit [Remote host closed the connection]17:08
*** rdale [] has joined #baserock17:11
*** rdale_ [] has quit [Ping timeout: 265 seconds]17:12
straycatpersia, Wrt what I just read on the list regarding documentation, I don't see how we can achieve much more than we're achieving currently, work on documentation is very ad hoc.17:22
straycatAlso, having finally read the huge thread on reproduceibility, I think that as persia says, we just need better tooling.17:58
*** genii [~quassel@ubuntu/member/genii] has quit [Quit: No Ping reply in 180 seconds.]19:07
*** genii [~quassel@ubuntu/member/genii] has joined #baserock19:08
persiastraycat: Sadly, I fear you might be right.  My issue is that most of the interesting things I want to do aren't well documented, but I'm not sure how to document them without making the existing documentation less good for folk trying to fgure out what can be done, or how to do it.19:15
ratmice_______there was a rant yesterday about docs on one of the gcc mailing lists, i haven't gotten around to watching it yet, but it linked to this talk
ratmice_______hopefully that url works, as my ability to copy/paste seems to have disappeared19:29
persiaratmice_______: Thanks for the link: it indeed works, and it worth watching, although a bit longer than it needed to be.20:06
persiaAnd it mentions a part of the documentation I failed to list: troubleshooting guides.20:06
persiaIt does express that the developers need to be the folk who write the docs, and explains why in a way that makes sense if one can be sympathetic to the speaker.20:07
persiaBut it doesn't magically provide motivation for folk to do so :)20:07
straycatWell it's time as well as motivation I think.20:08
persiaDepends on how one looks at it.  The speaker speaks from the perspective of django, where proper documentation is a requirement for code merge.20:12
persiaGiven that when something is done, the person developing it understands it clearly, it's a similar class of extra effort to write docs as tests, and possibly less as the docs aren't being executed so one can skip the syntax errors.20:13
persiaAs such, it becomes a matter of either 1) estimating the time to do something differently, or 2) spending more time polishing things before submission.20:14
persiaThat said, it takes a fair amount of commitment by everyone to decide that every code patch needs to include a relevant documentation fix.20:15
persiaAnd unless a plurality of the contributors genuinely want this, it is hard to impose.20:16
ratmice_______I do find it is helpful when reviewing patches, (when developing them not so much)20:35
ratmice_______well, I suppose helpful as motivation, but I tend to want to delay until after code review, which makes it not helpful for reviewers :)20:36
persiaThat's a strong argument for django's position :)20:37
straycatOh deary me21:12
straycatIt's a sign you've been doing something too long when you don't realise you've fixed your bug21:16
straycatI like the idea of providing documentation before merge21:18
persiaheh.  That only happens to me when I get involved in yak shaving, and end up moving off on a tangent.21:20
persiaI think documentation before merge works well for interfaces and reference documentation.  I'm less certain I understand how to do tutorials, guides, and troubleshooting docs in that model.21:21
persiaBut even if we just had outstanding reference documentation, I suspect I'd be happy (and it ought make it easier for folk working in other areas).21:21
persiaPerhaps guides could be written when someone does a cool new feature, showcasing the feature, and tutorials subtly adjusted when things get easier, or behaviour changes.21:22
straycatOn the other hand some of the documentation we've written ourselves hasn't been that great.21:22
persiaThat's OK.  When we have something, we can improve it.21:24
* straycat nods21:25
persiaI'm unsure that the wiki is the best place, because of how folk think about wikis.  In the talk there is a comment that wikis are where documentation goes to die.21:25
persiaBut our wiki is in git, so we ought be able to just fix stuff using patches, rather than needing to make special docs repos, write sphinx in them, and render them to somewhere.21:25
persiaI suspect it's mostly about mindset, really.  If we focus on docs like we do on code, it should all be fine.21:26
straycatI agree21:27
straycatIt's late here, I should probably eat something.21:30
* straycat disappears21:30

Generated by 2.15.3 by Marius Gedminas - find it at!