IRC logs for #baserock for Wednesday, 2014-09-17

*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]01:16
*** dutch_ [] has joined #baserock07:12
*** tiagogomes [~tiagogome@] has joined #baserock07:29
*** franred [] has joined #baserock07:44
*** dutch_ [] has quit [Quit: Quit]07:54
*** dutch_ [] has joined #baserock07:54
*** mwilliams_ct [] has quit []08:18
*** ssam2 [] has joined #baserock08:23
*** jonathanmaw [] has joined #baserock08:35
richard_mawI saw that problem before when I'd done an SVN import of a project that liked large binaries. I think the issue was cgit loading some of the objects into memory, or part of generating the per-commit tarballs.08:37
richard_mawthere's probably something we can tune, and a more recent cgit may behave better08:37
KinnisonWe might want to refresh to a more recent cgit anyway08:37
richard_mawbut I think it's the mariadb import that's causing problems08:37
Kinnisonit adds things like gravatar for authors/committers08:37
Kinnisonmariadb is imported now and should be clean unless git itself is killing things08:38
*** violeta [] has joined #baserock08:38
richard_mawthe specific error is lighttpd being unable to fork because it doesn't have enough memory08:43
pedroalvarezpatch sent to fix libevent08:44
Kinnisongbo has 12G of RAM08:44
KinnisonI wonder if we have too many vCPUs on it08:44
Kinnisongit operations can chew a lot of RAM08:45
KinnisonHmm, the mariadb repack is consuming 5G08:46
Kinnisonwhich is odd because lorry is supposed to configure it to limit the window size etc08:46
persiaCould run vmstat into a log for a while to check08:46
KinnisonUnfortunately busybox doesn't have vmstat08:46
paulsher1oodKinnison: i suggest we blow away mariadb before folks start to depend on it08:48
KinnisonI can do so, but it's a bit crappy08:48
persiaDo we not expect it to stabilise once the repack is complete?08:48
* Kinnison is examining things08:48
*** mwilliams_ct [] has joined #baserock08:53
ctgriffithsKinnison: If you need to nuke it we have other options, could you let me know what you decide?09:02
Kinnisonctgriffiths: Sure09:02
*** ctalex [] has joined #baserock09:11
KinnisonMariadb is the largest repo on gbo by a factor of five09:16
KinnisonI am tempted to drop the bzr import and request tarball imports09:16
ssam2that seems reasonable to me. I can't speak for everyone, but I've no desire to use unstable versions of MariaDB anyway09:21
Kinnisonctgriffiths: Would tarball imports be okay?09:23
ctgriffithsKinnison: I don't know, maybe paulsher1ood could advise?09:25
Kinnisonctgriffiths: are you expecting to do mariadb development, or just use it?09:25
*** liw-orc [] has joined #baserock09:26
ctgriffithsKinnison: just using it09:26
* Kinnison shall cancel the delta set from bzr import because it's just too damned big09:26
Kinnisonplease hold09:26
*** fay_ [] has quit [Ping timeout: 245 seconds]09:32
*** fay [] has joined #baserock09:32
fay is now known as Guest2139709:32
paulsher1oodis there a way to verify that dbus is alive on a genivi baseline system?09:36
Guest21397 is now known as fay_09:37
paulsher1oodor any system, for that matter?09:37
richard_mawif you can use systemctl, there's some form of dbus working, though it may just be the systemd private bus09:38
persiaIf you have a dbus client, you can check with that, but I doubt the dbus debug clients are part of a baseline system09:38
Kinnisondbus may also be socket-activated and thus not show up until you use it09:38
ssam2the baseline probably has `gdbus`09:39
paulsher1oodyes, gdbus is here09:40
ssam2Ok, I can work out a suitable invocation to test D-Bus. It'll take a few minutes :)09:40
persia`gdbus monitor --system` ought be a start, no?09:40
paulsher1oodError: destination is not specified09:41
persiaWhat dbus do you want to watch?09:42
ssam2paulsherwood: gdbus call --session --dest=org.freedesktop.DBus --object-path=/ --method=org.freedesktop.DBus.ListNames09:42
ssam2will list everything on the session bus, or fail if there's no session bus09:42
ssam2change --session to --system for the system bus09:42
ssam2I don't know if we start a session bus automatically in Baserock, I'd suspect not due to lack of PAM09:43
persiaFor instance, to check NetworkManager on my desktop, I can use `gdbus --monitor --system --dest org.freedesktop.NetworkManager09:43
ssam2paulsher1ood: that means there's no session bus, and gdbus tried to start one automatically09:46
ssam2but it failed because for some reason it must have an X session to do that09:46
ssam2if you set 'DISPLAY=:0' you might see success09:46
ssam2but of course, and empty bus09:46
ssam2*an empty bus09:47
radiofreeis that still the case, needs an X session?09:47
ssam2looks like the system bus is fine09:47
pedroalvarezgenivi-baseline doesn't have X09:47
ssam2It might work anyway. I'm not an expert on why it needs that.09:47
paulsher1oodso if system bus is fine can i assume dbus has survived my mangling?09:48
ssam2what did you mangle ?09:48
paulsher1oodi'll email the list...09:48
radiofreepaulsher1ood: i believe you can launch it without X09:48
radiofreejust set DBUS_SESSION_BUS_ADDRESS and make sure any app that needs it has that as well09:49
paulsher1oodno, just updatd - genivi-dev had notice of some vulnerabilities09:49
ssam2oh, yeah, it's only the autolaunch thing that needs X, not the daemon itself09:49
paulsher1oodradiofree: i'm sure you're right, but your instructions missed my head due to altitude :)09:50
radiofreeTo start a D-Bus session within a text\(hymode session, do not use dbus-launch. Instead, see dbus-run-session(1).09:50
*** dutch_ [] has quit [Ping timeout: 272 seconds]09:53
KinnisonI'm going to rm the mariadb stuff now09:57
persiait won't complete lorrying?09:58
KinnisonIt does, but at over 5.1G of repo it's a total pig09:59
richard_mawit's lorried AIUI, but it crashes the lighttpd serving cgit09:59
persiaThat's annoying.09:59
pedroalvarezan upgrade of cgit was also suggested, no?10:00
*** dutch_ [] has joined #baserock10:00
persiaLet's try that instead10:00
KinnisonI've removed the public side and the lorry but left the work area10:00
Kinnisonso if we decide gbo *can* cope with mariadb, it won't have to do the 60G reconvert10:01
persiaAh, good.10:01
Kinnisonthat's the best option I feel10:01
persiaWhat's the best way to test this?  Does testing depend on upgrades of g.b.o, or can we test a new lighttpd/cgit somewhere else, and only upgrade if it works?10:02
KinnisonWe ought to be able to test elsewhere10:03
Kinnisonwe can copy the repo manually10:03
persiaSounds like a reasonable plan10:04
paulsher1oodi've mailed the list on my dbus adventure10:06
* paulsher1ood looked at cgit updates a while ago and this seemed to be tightly coupled to git version10:16
richard_mawthat's why cgit embeds git in its repo10:17
pedroalvarezgood point10:19
richard_mawit may be better if it used libgit2, but AIUI it didn't exist when cgit needed it, and libgit2 isn't stable yet anyway, so you'd end up swapping a submodule of git for a submodule of libgit210:21
persiaIt wouldn't hurt to update git anyway: useful new features10:21
richard_mawpotential breakages though, since I think git's done the 1.x to 2.x transition now10:22
persiaRight, but the converse is becoming true, as more and more upstream projects become managed with git 2+10:26
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 272 seconds]10:45
KinnisonI think modern cgit has updated to git 2.x anyway10:47
pedroalvarezcan anybody take a look at the libevent patch?10:48
pedroalvarezI can't build distbuild systems now10:48
pedroalvarezIt has already a +1 from Sam, so I think the approach is good10:48
pedroalvarezssam2: is your +1 to the trove-setup patch (UPSTREAM_TROVE) still valid? 11:07
pedroalvarezI changed the implementation, so I don't want to take that +1 without your approval11:08
liw-orcpedroalvarez, I'd already skimmed through that patch series for libevent, but a belated +1 now11:09
pedroalvarezI will merge it11:10
*** tiagogomes [~tiagogome@] has joined #baserock12:11
*** tiagogomes [~tiagogome@] has quit [Read error: Connection reset by peer]12:15
*** nemos [] has joined #baserock12:46
pdar /NETSPLIT13:23
De|taNot recently?13:25
*** dutch_ [] has quit [Quit: Quit]13:39
*** dutch_ [] has joined #baserock13:39
*** franred [] has quit [Ping timeout: 245 seconds]13:49
*** franred [] has joined #baserock14:19
*** jjardon [sid723@gateway/web/] has quit [Read error: Connection reset by peer]14:36
KinnisonAnyone object to me looking at a newer cmake version?14:38
KinnisonA project I want to build (smartdevicelink) needs 2.8.11 and we have 2.8.914:38
persia\o/ updates!14:38
* Kinnison was going to update us to
Kinnisonas the latest non 3.x release14:38
Kinnison(who knows how compatible 3.x might be)14:39
persiaDo you have infrastructure that would let you test-build with 3.x without intense pain, just to see?14:39
KinnisonRight now I'm working with a small ARM distbuild cluster, so no, not really14:39
KinnisonAlso given I'm not a cmake guru, I wouldn't know whether it was a user fault or a cmake incompatibility, or a bug14:40
persiamakes sense14:42
* Kinnison kicks off a build with
Kinnison2014-09-17 14:42:56 Build steps in total: 149814:42
Kinnison2014-09-17 14:42:58 Progress: Need to build 1151 artifacts14:42
Kinnisonthis may be some time14:42
KinnisonAt least I have 4 workers \o/14:42
pedroalvarezgood :)14:43
persiaThere are 1151/1498 artifacts that require *cmake* ?!?14:43
Kinnisonpersia: No, but cmake is in core14:44
Kinnisonpersia: so things built with cmake end up as build-deps of other things14:44
Kinnisonand so the graph grows14:45
persiaAh, hrm.14:45
persiacore is perhaps overbroad, but I suspect that there's not much savings available from more granular stratification14:45
KinnisonIf we had 'morph hack' I could have tested modern cmake with the one chunk I wanted, and then later done the full test14:45
Kinnisonbut we don't (yet)14:45
persiaWhat would `morph hack` do?14:46
Kinnisonallow me to pull cmake up to my top level stratum where this thing is which needs it updating, let me update it and continue trying to integrate this tool, without needing to rebuild everything which b-d'd on the original cmake14:46
*** jjardon [sid723@gateway/web/] has joined #baserock14:46
Kinnisonthen at system construction time, it'd sub in, instead of the original cmake14:47
Kinnisonwhen putting the system together14:47
*** franred [] has quit [Ping timeout: 246 seconds]14:47
Kinnisoni.e. not good for releases, but really handy for hacking14:47
persia(As an aside, I find that I'm coming to like the use of "stratum" as a technical term, because all the natural grammatical uses happen to already exist as words in English)14:47
KinnisonI think Rob Taylor originally suggested it14:47
KinnisonPerhaps even on the ML14:47
liw-orcit was given to me when I started, before the ML existed, I think14:48
persiaI'm not movitivted enough to complain in depth now, but shall do so if anyone submits a patch to do that.14:48
persiaIt's deeply and fundamentally broken.14:48
ssam2robtaylor has since suggested using GNU Stow to achieve the same thing14:51
ssam2actually no, that was to achieve a different thing14:51
ssam2ignore me!14:51
paulsher1oodKinnison: would it  make sense to do this on x86 disbtuild first?14:51
Kinnisonpaulsher1ood: it might, but I'm all set up on the arm distbuild, and it's good to give the Jetsons a workout I think :-)14:52
* Kinnison is trying to get a more modern SDL than the one you integrated14:53
Kinnisonso that it has the Qt HMI14:53
Kinnisonand that means more modern cmake14:53
paulsher1oodoh, hold on a sec14:53
KinnisonI think I have everything else under control though14:53
paulsher1oodi ithink i integrated latest stable?14:53
KinnisonYou integrated release 1.014:55
Kinnisonrelease 3.0 is latest stable14:55
paulsher1oodbah. my y mistake14:55
* paulsher1ood goes to check if he pushed the wrong branch14:55
paulsher1oodi rememeber now - i moved the morph into definitions as first step, thne forgot about second step14:58
KinnisonYou'd have hit the need for a cmake update if you had14:58
*** franred [] has joined #baserock14:59
paulsher1oodKinnison: while you are on, please could you consider adopting/merging my baserock/ps/tidy-jetson patch?15:41
*** ssam2 [] has quit [Ping timeout: 245 seconds]15:43
* Kinnison looks at it15:44
KinnisonSure that all looks sane15:45
KinnisonIn fact it might make more sense to merge that to master and then I can rebase on top of it15:45
* Kinnison wonders if anyone else here has access to a Jetson and wouldn't mind taking Paul's patch, merging it to master and verifying nothing breaks?15:46
KinnisonAll my build nodes are "busy"15:46
paulsher1oodKinnison: how could anything break? i rename linux to something sensible, and add an upgrade cluster morph, is all :)15:53
paulsher1oodi did *test* it before i submitted, too :-)15:53
paulsher1oodbut if you insist i have a jetson here. what would you like me to try?15:54
Kinnisoneither a merge or rebase on top of master15:54
Kinnisonand a build15:54
*** ctalex [] has quit ["Ex-Chat"]15:55
Kinnisonpaulsher1ood: I appreciate that you are telling me what you did and that I agree I *see* it's right, but I'm good at failing to see syntax errors in yaml and json :-)15:55
Kinnisonpaulsher1ood: and I'd be a bad person to ask for a merge without at least a parse-the-build-graph check :-)15:55
Kinnisoncherry-pick, rebase or plain merge is fine15:55
* paulsher1ood misspooke, he has -several- jetsons here15:56
* Kinnison chuckles15:58
Kinnisonyou're rich in jetsons15:58
KinnisonJust don't "borrow" any of mine15:58
KinnisonI'm using 'em all15:58
paulsher1oodsadly, i have zero kettle leads. what's up with that ?15:59
*** ssam2 [] has joined #baserock16:06
* paulsher1ood misspoke again - they were ghiding in his briefcase16:10
*** dutch_ [] has quit [Quit: Quit]16:14
paulsher1oodKinnison: does convince you?16:15
paulsher1oodssam2: does convince you that i'm seeing minutes deciding wht to build?16:15
persiaIs that three minutes before it does anything useful?16:18
persiaTaking a minute to calculate the build set doesn't seem unreasonable, although I suspect it could usually start with a random order in parallel with that with equivalent or better performance.16:20
paulsher1oodto be fair, this is morph from a couple of months ago, it may be that current is faster16:20
paulsher1oodnote this is not distbuild16:20
persiaBut what part takes two minutes to decide to build the file requested for build?  Is this leftovers from the morphs-in-definitions stuff?16:20
paulsher1oodi have no clue16:20
pedroalvarezpaulsher1ood: have you used morph edit in that workspace?16:21
paulsher1oodit's fresh today16:22
paulsher1oodit's on a jetson, though16:22
persiaI wonder if those two minutes are spent validating the cache objects16:23
paulsher1oodall i did was morph branch b:b/definitions, then cherry-pick, then build16:23
persiaYou had previously worked in a separate workspace in that /src?16:24
ssam2paulsherwood: I need to go fairly soon, but running that command again with -v would be helpful to diagnose16:25
*** jonathanmaw [] has quit [Quit: Leaving]16:25
ssam2I have a hunch that the problem is the many individual network requests it makes to the cache, and the problem is much worse for you than for me due to some difference in network config or which trove we're using16:26
paulsher1oodi'm using gbo16:26
ssam2I thought so16:26
paulsher1oodi used to have my own trove. i may spin one up again soon :-)16:26
paulsher1ood(since it seems to have become trivial)16:27
ssam2we have an internal one that mirrors, too, named 'ct-mcr-1'16:27
paulsher1oodyou may be disappointed by -v output :)16:27
* persia would like less dependency on network operations16:27
* ssam2 would like more clarity over when network is required and advice how to achieve a setup where network is not be required16:28
persiaWhile they *can* be fixed by "just deploying a trove", this has non-trivial bandwidth and storage requirements.16:28
* paulsher1ood would like the moon on a stick16:28
ssam2*advice on16:28
ssam2ultimately, if you want to be able to build anything from the internet, you need network access16:29
straycata 'default' trove still requires a fair amount of memory though, I think.16:29
ssam2if you want to be able to build anything on a given Trove system, you either need network access to that Trove, or for the entire contents of that Trove to be stored locally16:29
Kinnisonpaulsher1ood: looks good to me16:30
paulsher1oodis that a +2? :-)16:30
ssam2(we can decide whether or not a given method of mirroring gits should be called 'Trove' or not, of course)16:30
persiassam2: Yes, but having hundreds of miscellaneous things happen adds up quickly when latencies grow, to the point where it isn't interesting to use the software unless you happen to be network-near a trove.  Surely there's some compromise.16:30
Kinnisonpaulsher1ood: Aye, you can have a +2 :-)16:31
persiaWhen working with traditional distros, I download a catalogue of available bimaries, and then download individual binaries, with an error if it was removed in the meantime.16:31
ssam2persia: there are several possible compromises, the trouble is: which ones?16:31
paulsher1oodKinnison: tvm. all i need now is someone with the super powers to merge it16:31
Kinnisonssam2: Feel like merging paul's jetson cleanup?16:32
ssam2need to leave soon, sorry16:32
persiassam2: So, what are the network operations that get performed?  I'd be happy to suggest which ones are uninteresting to me.16:32
Kinnisonssam2: bah :-)16:33
Kinnisonpedroalvarez: You?16:33
* Kinnison would do it but currently has all his stuff geared up on a local trove16:33
Kinnisonand I'm bound to fluff it if I try and do a partial revert to gbo16:33
pedroalvarezI will16:33
ssam2persia: my hunch about paulsherwood's system's slowness is correct, it's a bunch of calls to 'morph-cache-server' which do 'git rev-parse', 'git ls-files' and 'git cat-file' in order to calculcate a build graph and build instructions16:34
Kinnisonssam2: Mmm, I agree that your idea to batch those if possible would help a *lot*16:34
ssam2Kinnison: I've looked at doing it, but you're right that there's quite a bit of code rework needed16:34
paulsher1oodhere's the -v output
persiassam2: That's about what I thought.  Hrm.  I'd like to not to that, but that conflicts with my other want to not have local git cache anyway, so perhaps I'm not quite as happy as I thought :)16:35
* persia ponders16:35
ssam2paulsherwood: thanks16:35
ssam2seems that the first 2 minutes is spent working out if a temporary build branch needs to be created16:35
ssam2by examining all the files in your definitions working tree16:35
paulsher1oodso, let's scotch that. never do temp branches16:36
pedroalvarezjust aksing: temp branches in a local build?16:36
paulsher1oodas persia has suggested - only build head16:36
ssam2then there's 1 minute calculating the build graph and build instructions, mostly through local git cache access but some remote cache access too16:37
paulsher1ooduser commits, then commit --amend to repeat16:37
persiaNote that this does add effort for developers, who have to commit before building, and then clean up if they made a silly mistake with --amend16:37
ssam2I find the temporary build branch stuff takes 5 to 10 seconds, which I find annoying16:37
ssam2presumably paulsherwood's VM has very slow IO16:37
paulsher1oodthat's not effort, persia. i'm tempted to script it :)16:37
paulsher1oodit's not a VM16:37
paulsher1oodit's baserock, on jetson16:38
ssam2ah, right16:38
persiaShouldn't be too slow IO, if it's SSD16:38
*** genii [~quassel@ubuntu/member/genii] has joined #baserock16:38
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]16:38
ssam2yeah, that's a little strange.16:38
ssam2maybe you have lots of chunk repos checked out, so it's looking in those too16:38
ssam2certainly I'd be in favour of making it possible to disabling temporary build branches16:38
paulsher1oodi have nothing checked out16:39
paulsher1oodat least not in this branch16:39
ssam2right. I'm surprised it takes so long, then. I won't speculate further without seeing it in action16:39
paulsher1oodi'm here all week :-)16:39
ssam2I can look tomorrow at making it possible to disable temporary build branches, it should be a small job16:40
richard_mawlet's try disabling the adding uncommitted changes first16:40
ssam2richard_maw: oh, that's what I mean actually16:40
ssam2it's the 'examine the entire working tree' part that is slow16:41
ssam2thanks for pointing that out16:41
Kinnisonssam2: I think the major work is that we currently do an in-place visit of everything and expect it to fill in as we go.  If we could do a pre-traverse and gather all the questions, ask them in one go, annotate, and then do the in-place traversal, it might work without changing too much16:41
Kinnisonssam2: alternatively we have to rework the core loop, but I'd not be upset if it were slightly less coupled :-)16:41
ssam2Kinnison: some of the loop is still written as if strata can be in multiple repos, probably16:42
ssam2since they're all in definitions, it should be possible to look at every stratum, build a graph, then query ref and build-system for every chunk in one go16:42
* Kinnison still wants that data cached in the definitions commit but appreciates that might be hard16:44
persiaThe main issue is that it's really hard to enforce it remains valid.16:44
KinnisonIt can be made so that it'll always be valid, but not always be useful16:45
persiaYes, but unless it's useful, it's not even interesting!  We want both valid and useful, or we require a network operation.16:46
KinnisonWell, when I said "not always be useful" I meant that it may not always be *complete*16:47
Kinnisone.g. if you change a ref for a chunk and commit that without letting morph update the cache, it may not be complete16:47
persiaI meant that with "valid" :)16:48
KinnisonI'm now very confused :-)16:48
KinnisonBut I am shattered and slightly unwell, which will be contributing to that16:48
persiaBut I can also commit a change involving causing new chunks to appear or old chunks to be removed, which causes greater grief.16:48
pedroalvarezpaulsher1ood: is there a branch for the patch that I'm supposed to merge?16:50
Kinnison16:42 < paulsher1ood> Kinnison: while you are on, please could you consider adopting/merging my baserock/ps/tidy-jetson patch?16:51
Kinnisonpedroalvarez: ^^^16:51
pedroalvarezKinnison: ta16:51
pedroalvarezbut that branch is not pushed16:53
pedroalvarezit is16:53
paulsher1oodit's been a long day. beer o'clocl16:53
* straycat likes these nova tools16:54
richard_mawOpenStack is pretty cool16:54
paulsher1oodOpenStack + Baserock is extra cool :)16:54
* richard_maw wonders if the pun in Nova's name is a refernce to Short Circuit16:54
pedroalvarezi will provide some instructions about how to create a  distbuild network of many workers and a controller  in openstack with only one image :)16:56
paulsher1oodpedroalvarez: i'll happily try them :)16:57
pedroalvarezpaulsher1ood: baserock/ps/tidy-jetson merged16:57
straycatIf you're doing that could you write them as separate docs, the docs we have now are getting a bit long.16:58
paulsher1oodstraycat: it's time we separated out openstack i think16:59
* straycat nods16:59
pedroalvarezstraycat: yeah, the one with info is pretty big now16:59
pedroalvarezwith trove deployment info, I mean16:59
straycatpaulsher1ood, planning to split that up quite soon17:00
paulsher1oodgreat :-)17:00
straycatthe original trove doc I wrote wasn't too good in the first place and could use some improvement17:00
*** liw-orc [] has joined #baserock17:01
*** ctgriffiths [] has joined #baserock17:01
*** ratmice_______ [] has joined #baserock17:01
* paulsher1ood volunteered to write docs ages ago, then failed to actually do so 17:02
pedroalvarezI'd like to  have a versioned documentation17:02
ssam2petefoth likes writing docs ;)17:02
pedroalvarezwith versioned documentation I mean, diferent documetnation for every release17:03
paulsher1oodinteresting idea17:04
paulsher1oodfirst step, put the wiki doc onto gbo17:04
pedroalvarezmany projects do that17:04
*** violeta [] has quit [Ping timeout: 272 seconds]17:07
*** tpollard [] has quit [Quit: Ex-Chat]17:15
*** ssam2 [] has quit [Remote host closed the connection]17:22
*** franred [] has quit [Quit: Leaving]17:28
*** nemos [] has quit [Ping timeout: 258 seconds]18:22
pedroalvarezregarding my idea of "versioned documentation". This is an example:
pedroalvarezdjango also uses read-the-docs18:39
pedroalvarezI think it takes the documentation from git repositories.18:39
pedroalvarezAnybody has opinions on this?18:40
KinnisonIt's an interesting idea.  django's docs are usually good, but how much of that is readthedocs and how much is just django's team I don't know :-)18:41
* paulsher1ood is in favour of exploring this18:56
persiareadthedocs is just a nice sphinx browser, so give credit to the team for the content, and readthedocs for the presentation19:13
persiaWIth versioned docs, one usually wants to maintain them in parallel trees, so that one can apply patches sanely when docs for an older version would benefit from a fix.19:14
persiaNote that this also requires a versioned release of the thing documented, so we'd want to have the conversation about morph releases again.19:15
paulsher1oodagain? :)19:31
persiaYep.  We'll probably keep having it until ether 1) we decide to have stable/development branches of morph with releases or 2) we give up on versioning anything19:34
pedroalvarezI'm probably going to take a look at the integration of this read the docs.19:42
pedroalvarezjust for fun (for now)19:42
pedroalvarezand yeah, it only makes sense if we do versioned releases of moprh19:43
pedroalvarezor if we do versioned releases of baserock devel systems19:43
pedroalvarezI've raised this idea because in some places of the wiki we have documentation for latest morph, in other places documentation for an old morph, and everything mixed19:45
persiaMy memory is that it goes the other way around: the project exports sphinx, which readthedocs integrates, but I may be mistaken19:52
persiaI'm still opposed to versioned releases of baserock devel systems, because it's rare that whatever gets released is useful to me, and I don't believe it possible to make a release of a devel system that is useful to several different folk.19:53
pedroalvarezI kind of agree, but sometimes we add some chunks needed to use morph, but yes you can also build it and deploy it to your system. But how do you get your first devel system?20:09
* paulsher1ood can't remember what caused the 'Failed to open frame buffer device' error
pedroalvarezKERNEL_ARGS in your cluster morphology20:09
pedroalvarezone sec20:09
paulsher1oodgah! :)20:09
paulsher1oodtvm - i'll find it20:10
persiapedroalvarez: First devel system should be whatever would be built from HEAD of definitions, in my mind20:10
pedroalvarezpaulsher1ood: I think the clusters/release.morph has an example of how to deploy genivi baseline, (it needs that kernel arg too to make framebuffer work)20:11
* paulsher1ood gives jjardon a +1 and hopes someone else will follow suit :)20:21
rjek+1 for Django's docs.  It's easy to navigate and switch between releases.  The actual text varies in quality, though.20:46
pedroalvarezAnnouncement: Public mason IP has changed. In my attempt of releasing the old IP and allocate the same IP for a fresh deployed mason instance, I lost it.21:34
pedroalvarezNew ip:
pedroalvarezAgain, this is a "work in progress", but is nice to have it in public.21:35
paulsher1oodnice to see a PASS to start, too :)21:46
rjekThis is why we have DNS with low TTL :)22:07
persiarjek: The issue is that we don't seem to have a good API to update the DNS22:20
rjekDoes Mythic Beasts not provide an API?22:22
* rjek tsks.22:22
* rjek also creates a card on the Pepperfish kanban to provide an API for updating DNS.22:22
persiaPepperfish manages baserock DNS?22:23
rjek(Although the URL and post scheme for the web interface is trivial to drive from scripts.)22:23
rjekpersia: No.  But it does host its mailing list.22:23
rjekMythic Beasts handle's DNS IIRC22:23
rjekWHOIS confirms this.22:23
* persia reads
rjekLooks like Mythic Beasts have an API :)22:24
persiaUgh.  Passwords.22:24
rjekOver SSL at least.22:25
persiaYeah, but it means we either need to distribute the password, or have some service with rational authentication that proxies.22:25
* rjek makes a note to rip that API off, but instead of a password allow users to generate and revoke API keys from the human web interface.22:25
rjekService credentials and public version control are always a headache.22:26
persiaDoesn't solve the secrets problem for situations where the dynamic IP is hosted on untrusted infrastructure22:26
rjekIt does let you limit what they can access, though22:27
persiaThere's a few projects out there for this sort of thing.  Designate, for example.22:27
rjekAnd if you're doing things on untrusted infrastructure, you may have already lost.22:27
* persia almost always does stuff on untrusted infrastructure: trusted infrastructure is expensive and doesn't have high-grade internet access22:28
rjekActually, a solution would be to generate a token that is actually a shared secret, and you hash your modification request with the token.22:28
rjek(ie, poor man's digital signature)22:28
rjekStops sniffing, at least.22:29
persiaHash won't do it: you need reversible encryption.22:29
rjekGets more complex if you want to prevent replay, obviously.22:29
rjekyeah, the shared secret is still on the box you don't trust that's also building software you run as root :)22:29
persiaPresumably one isn't planning on running that software on trusted infrastructure22:30
persiaOr one would have gone to the effort of constructing everything in a trusted manner in the first place, and this would not be a problem (as one could safely share the disposable secret inside the trust domain)22:30
persiaBetter docs on Mythic Beasts DNS API:
persiapedroalvarez: Dunno if you have the password, but you might want to put together something that lets you set DNS entries, rather than needing bare numbers, and then chase whoever has the password to run it.22:37
pedroalvarezSooner or later we will have to create dns entries 22:42
pedroalvarezI'm not sure if this has to happen automatically 22:44
persiaI don't think it can happen automatically right now, but I think that if there is a script to do it, the person who knows the password might be more willing to do it.22:48
persiaOf course, this presumes there exists someone who knows the password :)22:48
radiofreelots of assumptions23:38
radiofreethough i'm not best qualified to comment on this considering i think baserock systems should have a default password23:39

Generated by 2.14.0 by Marius Gedminas - find it at!