[02:05] <wallyworld> axw: meeting?
[02:05] <axw> wallyworld: sure
[02:05] <wallyworld> rotating team meeting
[02:05] <wallyworld> see cal
[02:05] <axw> oh right, core team
[02:05] <axw> whoops
[02:06] <wallyworld> :-)
[02:07] <wwitzel3> perrito666: if you're still around
[02:37] <wallyworld> thumper: want the 1:1 now?
[02:37] <thumper> wallyworld: yeah, in our normal hangout
[02:38] <wallyworld> already there :-)
[03:04]  * thumper goes to make a coffee
[03:21] <sinzui> axw, I updated bug 1324255 to explain that the juju and the slave were dead from disk shortage and zombie mongos. from other tests
[03:21] <_mup_> Bug #1324255: Local provider cannot boostrap <ci> <local-provider> <mongodb> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1324255>
[03:22] <axw> sinzui: hmm ok. I'm pretty sure I saw it on the amd64 tests to
[03:22] <axw> too*
[03:24] <sinzui> axw, CI doesn't have a trusty local lxc test yet
[03:24] <axw> sinzui: sorry, I was unclear; I meant the unit tests themselves see the "Closed explicitly" error. not in local deployment, just running the unit tests
[03:24] <axw> sinzui: e.g. http://juju-ci.vapour.ws:8080/job/walk-unit-tests-amd64-trusty/485/console
[03:24] <axw> it may be unrelated, I'm not sure
[03:26] <sinzui> I see
[04:22]  * thumper making dinner, back in about 2 hours for a bit more
[05:06] <waigani> https://codereview.appspot.com/98700043 :)
[06:15] <wallyworld> axw: thanks for review, more info on reason for new interface etc is here https://docs.google.com/a/canonical.com/document/d/1J6EZ37gfiZdVMdoxdFrih4R27LCcqyBzi50wjWFjbiA
[06:18] <axw> okey dokey, will have a read
[06:18] <axw> wallyworld: I think calling it "err" will also be a problem, because an "err" in the body will shadow it
[06:19] <wallyworld> axw: err in body is not meant to be a new var
[06:19] <wallyworld> that's why i used = not :=
[06:19] <axw> wallyworld: not on the first line of the function
[06:20] <wallyworld> that's because file is new but err will not be as it's the 2nd var and there's one in scope
[06:20] <wallyworld> or have i got that wrong?
[06:20] <axw> mm I think it only counts if it's declared in the same scope. will verify
[06:20] <axw> I could be full of crap
[06:20] <wallyworld> the err at the top is in the same scope afaik
[06:20] <wallyworld> bbiab, gotta pick up kid
[06:21] <wallyworld> axw: i was tempted to leave the err in the defer as err := but thought it could be confusing so changed its name even though not necessary
[06:21] <axw> wallyworld: you are correct
[06:21] <wallyworld> np
[06:22] <wallyworld> that's why i hate := and =
[06:22] <wallyworld> too easy to make subtle mistakes
[06:22] <wallyworld> now i'm really bbiab
[08:08] <voidspace> morning all
[08:30] <voidspace> is anyone working on the "juju doesn't bootstrap on precise" issue?
[08:30] <voidspace> I suspect it's my fault
[08:31] <voidspace> I'm spinning up a precise VM to look at it
[09:06] <axw> voidspace: if you can reproduce it, I have a small change I'd love to test
[09:07] <axw> I'll also start a precise image on AWS
[09:08] <voidspace> I'm creating a local VM. Still downloading precise - my "old" VM was 13.10 not precise.
[09:11] <axw> voidspace: from what I've found in Googling, it seems that mgo will kill sockets for servers that it doesn't think are available in the cluster
[09:11] <axw> voidspace: so I've made a small change to copy (rather than clone) the session when running replSetInitiate, to force it to create a new socket
[09:14] <vladk> jam: ping
[09:18] <jam> vladk: pong
[09:19] <vladk> jam: I'd like to discuss my further steps in developing Networker API
[09:19] <jam> sure, can we get dimitern involved as well?
[09:20] <vladk> jam: of course
[09:20] <jam> (well that was mostly just to ping him)
[09:20] <vladk> dimitern: ping
[09:21] <vladk> jam: can we do it on hangout?
[09:21] <jam> certainly, I was just waiting to see if dimitern was actually around
[09:24] <dimitern> jam, vladk, i'm here
[09:25] <jam> k I need about 30s
[09:26] <jam> we can just use our team standup hangout
[09:27] <jam> https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
[09:27] <jam> dimitern: vladk ^^
[09:29] <fwereade> axw, pre-commented on https://codereview.appspot.com/102860043/ -- let me know if it sounds sane to you
[09:31] <voidspace> axw: awesome, that sounds very useful
[09:31] <voidspace> axw: might help test issues as well
[09:31] <voidspace> axw: we start mongo ok, but then fail to connect to it
[09:31] <voidspace> axw: (when using replica sets for tests)
[09:31] <voidspace> axw: and it's not a timing issue, we wait sixty seconds
[09:32] <voidspace> axw: I'm creating a branch with my changes backed out - so once I get the VM setup I can quickly tell if it's my changes
[09:32] <axw> fwereade: thanks, seems sensible to put it on RelationUnit. in my PoC I did the address selection TODO in the uniter, which is a bit dumb I guess.
[09:32] <axw> fwereade: yes, free for a chat tomorrow
[09:32] <axw> voidspace: we wait sixty seconds for what?
[09:33] <voidspace> axw: we wait up to sixty seconds (mongoDialupTimeout I believe) when trying to connect to the mongo server we have created for tests
[09:33] <voidspace> axw: you're missing some context
[09:34] <voidspace> axw: as well as using replica sets for local provider I wanted to switch us to using replica sets for tests too
[09:34] <axw> I see
[09:34] <voidspace> axw: so that our test mongo matches the production mongo
[09:34] <axw> we're already doing that in a bunch of tests - you want to do it in *all* of the,?
[09:34] <axw> them*
[09:34] <voidspace> axw: but when I do that, many tests fail with "unreachable servers" - many of them deterministically
[09:34] <voidspace> axw: yep
[09:34] <axw> ok
[09:35] <voidspace> JujuConnSuite *doesn't*
[09:35] <voidspace> the driving motivator is that we want to switch to write-majority
[09:35] <axw> sounds like it will add quite a bit of overhead to the tests. setting up a replica set can take quite some time
[09:35] <fwereade> axw, no worries, we converge :)
[09:36] <voidspace> the command to switch to "write majority" (WMode) errors if you're not using replica sets
[09:36] <axw> :/
[09:36] <voidspace> so one fix is to use replica sets everywhere
[09:36] <voidspace> that's what we were attempting
[09:36] <voidspace> it maybe that because of precise we *can't*
[09:42]  * axw sighs
[09:42] <axw> of course it bootstraps first time for me
[09:42] <axw> of course it'd help if I had pulled trunk
[09:42] <voidspace> heh
[09:51] <voidspace> axw: this branch reverts my local provider replica set changes
[09:51] <voidspace> axw: lp:~mfoord/juju-core/revert-local-replset
[09:51] <axw> ok
[09:51] <voidspace> or "bzr merge -r 2803..2802"
[09:58] <axw> voidspace: if you manage to reproduce the error with replSet enabled, try this patch: http://paste.ubuntu.com/7542857/
[09:58] <axw> (please)
[10:00] <voidspace> axw: yep
[10:00] <voidspace> axw: precise installing now
[10:00] <voidspace> axw: you couldn't reproduce?
[10:00] <axw> voidspace: nope :(
[10:00] <voidspace> odd
[10:03] <wallyworld> mgz: 1:1 time
[10:13] <mgz> wallyworld: whoops, not looking, joining now
[10:17] <axw> voidspace: it's not just precise. http://juju-ci.vapour.ws:8080/job/local-deploy-trusty-ppc64/
[10:17] <axw> there's a bunch of failures there on r2807
[10:18] <axw> "no reachable servers"
[10:28] <voidspace> axw: :-/
[10:28] <voidspace> axw: configuring my vm to try it
[10:31] <voidspace> 215mb of updates...
[10:35] <menn0> hi all
[10:36] <voidspace> menn0: morning :-)
[10:37] <voidspace> menn0: howsit?
[10:37] <menn0> voidspace: alright
[10:37] <menn0> voidspace: how are you?
[10:37] <menn0> voidspace: we had a bit of household chaos here this afternoon so I'm catching up now. have one big email to send to #juju-dev today. I'm off until Tuesday.
[10:39] <voidspace> menn0: ah, fun
[10:39] <voidspace> menn0: I hope "household chaos" is good chaos
[10:39] <menn0> voidspace: not really, but all fine now
[10:41] <voidspace> menn0: :-/
[10:41] <voidspace> we're all good here, lots going on
[10:41] <voidspace> better a hectic life than a boring one though
[10:42] <voidspace> trying to reproduce precise bugs at the moment
[10:42] <menn0> voidspace: I think there's a balance :)
[10:42] <menn0> voidspace: yeah I heard about that problem
[10:42] <menn0> voidspace: tricky to reproduce?
[10:43] <voidspace> menn0: so far
[10:43] <voidspace> menn0: I'm just updating and configuring a precise vm to see if I can reproduce
[10:43] <voidspace> axw has failed so far
[10:56] <menn0> thumper: hi again :)
[10:56] <thumper> o/
[11:01] <alexisb> cmars, fwereade: joining us?
[11:03] <natefinch> ahhhh stupid hangouts keeps crashing
[11:11] <voidspace> natefinch: morning
[11:18] <natefinch> voidspace: morning
[11:51] <voidspace> so if I try to bootstrap with the local provider on precise it tells me that juju-local is required
[11:51] <voidspace> but juju-local is also unavailable for precise
[11:51] <natefinch> ahh hrm
[11:51] <voidspace> do I need to add a ppa?
[11:51] <voidspace> looking
[11:53] <voidspace> natefinch: "Due to needing newer versions of LXC the local provider does require a newer kernel than the released version of 12.04."
[11:53] <voidspace> Therefore we install Linux 3.8 from the LTS Hardware Enablement Stack:
[11:55] <voidspace> natefinch: I've added ppa:juju/stable and juju-local is now available
[11:55] <voidspace> looks like I need to upgrade the kernel too
[11:56] <axw> voidspace: I used cloud-archive:tools
[11:56] <voidspace> axw: is there a difference?
[11:57] <voidspace> I guess "stable" is likely to be out of date
[11:57] <axw> I mean to get the newer lxc
[11:57] <voidspace> ah
[11:57] <voidspace> hmmm
[11:57] <axw> hm, I guess you got an older 12.04, I probably got 12.04.03
[11:57] <voidspace> I did a full update
[11:58] <axw> ok I dunno
[11:58] <voidspace> axw: those quotes were from the docs, not an error message
[11:58] <voidspace> https://juju.ubuntu.com/docs/config-LXC.html
[11:59] <voidspace> axw: I might try without the new kernel first
[11:59] <voidspace> maybe it will fail in the same way...
[11:59] <mgz> voidspace: `sudo apt-add-repository cloud-archive:tools` if you've not
[11:59] <voidspace> although Curtis is pretty switched on, so I doubt that's the problem
[11:59] <voidspace> mgz: ok
[12:00] <voidspace> mgz: you sound like you know what you're talking about :-)
[12:00] <mgz> worth checking your kernel version too, by default upgrades may not give you a newer kernel
[12:00]  * axw disappears
[12:00] <voidspace> axw: o/
[12:00] <mgz> night axw
[12:00] <voidspace> mgz: they're unlikely too
[12:00] <voidspace> *to
[12:01] <voidspace> mgz: would you reccommend I remove the juju/stable ppa?
[12:02] <mgz> if you're not trying to use the *client* we have released on that machine, yes
[12:02] <vladk> jam. dimitern: what is your way to keep go packages up to date?
[12:02] <vladk> 'go get -u ./...' damages my working juju-core, so I wrote a script http://pastebin.ubuntu.com/7543496/
[12:02] <mgz> vladk: yeah, go get is dangerous
[12:03] <jam> vladk: I generally run just "godeps -u dependencies.tsv" and then go update the ones that are out of date
[12:03] <jam> you can just "go get -u github.com/juju/errors/…" for example
[12:03] <mgz> vladk: ^that's what I do too
[12:03] <voidspace> mgz: I'm trying to use trunk, thanks
[12:03] <mgz> well, I don't use go get at all, I pushd to the branch and git pull or whatever
[12:04] <jam> mgz: sure, I've done that as well, depends on my mood, I guess
[12:05] <mgz> jam: and yeah, I do use go get as well, if say we've added a new dep with its own deps
[12:05] <voidspace> ok, installing new kernel
[12:05] <voidspace> so lunch
[12:06] <vladk> vladk: jam, mgz: I want to update all of packages
[12:14] <dimitern> vladk, that's a handy script, thanks
[12:14] <wwitzel3> hello
[12:15] <voidspace> wwitzel3: morning
[12:15] <voidspace> so, juju bootstrap on precise, with trunk, seems to work fine for me
[12:15] <wwitzel3> so after not sleeping more than 5 hours the last 3 days, I finally zonked out and managed to sleep 10 hours.
[12:15] <vladk> dimitern: use with care, not fully tested, I'm not sure about pull options
[12:15] <wwitzel3> feels good, like I'm sane again :)
[12:15] <voidspace> going on lunch
[12:15] <voidspace> will dig deeper after that
[12:19] <thumper> night folks
[12:20] <dimitern> vladk, sure, i'll give it a try
[12:21] <voidspace> wwitzel3: that's good news, welcome back to the land of the living
[12:22] <wwitzel3> voidspace: thanks, enjoy lunch
[13:03] <alexisb> cmars, hazmat, fwereade: omnibus review
[13:05] <perrito666> good sort of morning
[13:08] <mgz> sort of morning?
[13:09] <perrito666> mgz: I usually start around or before 7AM now its 10
[13:11] <mgz> sinfully late
[13:45] <wwitzel3> perrito666: it is a trend today, I didn't get on until just after 8 and I even went to bed right after the meeting last night.
[13:47] <perrito666> wwitzel3: I did too, it was like midnight when the meeting ended, but this AM I just spent 2.5hs in a queue trying to do some bureaucracy and then an extra half an hour having to exit and re enter the city because the path to go trough the center was blocked by a cluster of strike protests
[13:48] <wwitzel3> that sounds less fun than sleeping
[13:48] <perrito666> yep
[13:48] <wwitzel3> fwereade: ping
[13:48] <fwereade> wwitzel3, pong, listening, but in meetings, so responding slowly
[13:50] <wwitzel3> fwereade: np, I was pretty dense yesterday and I don't think I retained the full value of our earlier conversation.
[13:51] <wwitzel3> fwereade: looking at the presence code, I'm not seeing us actually use WaitAgentPresence anywhere. We define it and have tests.
[13:51] <wwitzel3> fwereade: I'm wondering if we should just be using that with or instead of SetAgentPresence in the Pinger.
[13:52] <fwereade> wwitzel3, not quite following -- I know we don't use WaitAgentPresence except in tests, though, but I don't get the larger thread
[13:53] <wwitzel3> fwereade: part of the problem is I'm still cloudy on the "Why" SetAgentPresence doesn't think the agent is there when it is called the first time.
[13:53] <fwereade> wwitzel3, I *think* it's because it uses "2 consecutive pings" as the "yep, it's there" condition
[13:54] <fwereade> wwitzel3, but please validate that against reality
[13:54] <fwereade> wwitzel3, (ie if you've only had one ping it's not yet considered presence)
[13:58] <natefinch> Wow, I just realized the Juju Core Team meeting was last night not tonight.  Stupid time zones making my Thursday meeting on Wednesday :/
[13:59] <perrito666> yup, do we have stdup today?
[13:59] <voidspace> hah
[13:59] <perrito666> I just set up an alarm for the day before, so I know in advance when that meeting is
[14:00] <natefinch> I had skipped thursdays, because we used to have the juju core meeting before it, but now that the juju core meeting is moving, I think I need to reinstate the thursday standup.  Short answer: yes
[14:00] <wwitzel3> fwereade: I'm not seeing the two pings, following the trail from api status -> machine.AgentPresence -> presence.Alive which which fires a watcher.sendReq for the machine key and we select over the result and return bool,err back up the stack.
[14:02] <wwitzel3> fwereade: I can make the problem with a long enough wait and recalling SetAgentPresence, but that isn't a legitimate fix and I am still failing to really grok the problem in the first place.
[14:03] <natefinch> wwitzel3, voidspace: standup?
[14:03] <wwitzel3> natefinch: oops, sorry
[14:03] <natefinch> wwitzel3: it's ok, it wasn't on the calendar for today until now
[14:19] <dimitern> fwereade, natefinch, mgz, I'd love a review on this networks constraints CL https://codereview.appspot.com/102830044
[14:20] <dimitern> wow! LP now supports inline comments on MP diffs! \o/
[14:20] <voidspace> wow
[14:20] <dimitern> is it too late now to not switch to github? :D
[14:21] <wwitzel3> dimitern: hah
[14:23] <natefinch> haha
[14:24] <natefinch> fwereade: did you and Ian figure out if we should use --replset in tests?
[14:24] <fwereade> wwitzel3, ok, I may be wrong there: is it just the case that the first ping is not landing quickly enough to be seen?
[14:25] <fwereade> natefinch, essentially yes
[14:26] <fwereade> natefinch, for the tests that *by their fundamental nature* require mongo, we should be using --replset, because those really are integration tests and we should mimic a real environment as closely as possible
[14:27] <fwereade> natefinch, but we have many tests that only coincidentally require mongo, and in those cases --replset is not required, because we should be aiming to make those tests unitier anyway -- to the point where they don't depend on mongo
[14:28] <fwereade> natefinch, in particular replset clearly needs a real mongo, and almost certainly peergrouper too; and very probably state
[14:29] <fwereade> natefinch, other test that merely happen to use state should be migrating away from the mongo dependency anyway, and so the loss of --replset is not a big deal
[14:29] <fwereade> natefinch, how upsetting is this from your perspective?
[14:30] <voidspace> sinzui: ping
[14:30] <sinzui> hi voidspace
[14:30] <voidspace> sinzui: ah, actually ping for five minutes
[14:30] <natefinch> fwereade: it seems very squishy.  Deciding if a test "really" needs mongo is non-trivial.
[14:30] <voidspace> I assumed you'd be slower :-)
[14:31] <fwereade> natefinch, well, state/presence and state/watcher are the other two definite ones
[14:31] <natefinch> fwereade: btw are you on the cross team meeting, or should I jump on?
[14:31] <fwereade> natefinch, but generally anything we *could* back with a double for state.State is IMO a candidate
[14:32] <fwereade> natefinch, I'm not, alexis is; your presence couldn't hurt though :)
[14:32] <natefinch> heh ok
[14:36] <wwitzel3> fwereade: thank you, I think you've given me an epiphany
[14:56] <voidspace> I've been asked to speak at PyCon India
[14:56] <voidspace> A good opportunity to promote juju
[14:56] <voidspace> Have to work on a snappy demo
[14:57] <natefinch> Cool
[15:00] <perrito666> voidspace: sweet
[15:00] <perrito666> voidspace: you can try the one from LAS
[15:00] <bodie_> fwereade, did you get a chance to check out my MR?
[15:01] <voidspace> perrito666: Las Vegas?
[15:01] <voidspace> that was pretty IBM centric
[15:01] <bodie_> I'm looking for direction to either dig deeper on the gojsonschema to add (id) references, or to move forward towards state and param validate
[15:01] <voidspace> something equally impressive though I hope
[15:01] <perrito666> voidspace: yes, but nevertheless pretty
[15:01] <voidspace> yep
[15:01] <voidspace> something python related would be good
[15:02] <perrito666> voidspace: some of the material used on the os demo, minus the lego part
[15:02] <voidspace> I'll talk to the online services guys as they're charming up their infrastructure
[15:02] <mgz> bodie_: I'm on it
[15:02] <voidspace> deploying and updating a django app would be good
[15:02] <voidspace> and scaling out
[15:02] <dimitern> fwereade, mgz, natefinch, a gentle reminder about https://codereview.appspot.com/102830044/
[15:02] <bloodearnest> voidspace: oi! that's my planned demo for PyConUK :D
[15:03] <voidspace> bloodearnest: awesome, I can use yours
[15:03] <mgz> dimitern: I'm not wild about that syntax...
[15:03] <voidspace> oops, I mean "we can work on it together"...
[15:03] <dimitern> mgz, it's decided from above
[15:03] <perrito666> voidspace: sure you meant that :p
[15:03] <mgz> dimitern: code seems fine so far
[15:03] <voidspace> :-)
[15:04] <dimitern> mgz, I'll wait for jam and/or fwereade  to take a look as well, because i'm not sure about a few bits, but any comments are welcome
[15:04] <perrito666> voidspace: that is cool, I only get invited to pycons I cant afford at times I cant travel :p
[15:05] <bloodearnest> voidspace: when is pycon india?
[15:05] <voidspace> perrito666: right, thankfully they're covering the costs or I wouldn't be able to afford it either
[15:05] <voidspace> bloodearnest: end of September
[15:05] <voidspace> so after PyCon UK I think
[15:05] <bloodearnest> kk
[15:05] <bloodearnest> voidspace: so we should do a joint talk proposal for pyconuk then :)
[15:06] <bodie_> thanks mgz, nothing too fancy really.  just got your changes in to the github repo (all tests are green) but need to make a decision about gojsonschema itself
[15:07] <voidspace> bloodearnest: heh, yeah - sounds good
[15:07] <bodie_> fwereade indicated interest in getting it MR'd as such even if it's not a "real" merge request, just to get visibility
[15:07] <sinzui> voidspace, http://pastebin.ubuntu.com/7544599/
[15:08] <voidspace> sinzui: looking, thanks
[15:08] <sinzui> voidspace, I asked abentley to join us to discuss what the test is doing bad
[15:09] <voidspace> sinzui: so that worked
[15:10] <voidspace> sinzui: ok
[15:10] <voidspace> sinzui: although revision 2802 on master worked
[15:10] <voidspace> so *something* changed
[15:10] <voidspace> abentley: hello
[15:10] <abentley> voidspace: Hi.
[15:11] <sinzui> voidspace, yes, but the only thing I think changed is that I renamed the test to from local-deploy to loca-deploy-precise-amd64
[15:11] <voidspace> heh
[15:12] <voidspace> it was failing deterministically before that
[15:12] <sinzui> abentley, voidspace I can try to restore the test name
[15:13] <voidspace> that *really* shouldn't make any difference
[15:13] <sinzui> oh but ci is still running
[15:13] <sinzui> I can copy the test to the old name
[15:13] <sinzui> oh, voidspace, I haven't run upgrade yet. I will do that to get the new lxc
[15:13] <voidspace> sinzui: so the initial manual bootstrap works, but we think that re-bootstrapping from the generated .jenv file doesn't?
[15:14] <abentley> sinzui: Are you re-bootstrapping from old jenvs?
[15:14] <sinzui> abentley, voidspace, the env name and the pregenerated jenv are the difference
[15:14] <voidspace> or by "generated jenv file", do you mean your pre-canned one?
[15:14] <sinzui> abentley, I used true local with a jenv
[15:15] <sinzui> abentley, I used true local withOUT a jenv
[15:16] <voidspace> can I get a copy of the failing jenv file?
[15:16] <abentley> sinzui: And you used an old jenv for testing local-deploy-precise-amd64?
[15:17] <abentley> voidspace: We don't have a pre-canned jenv.
[15:17] <voidspace> I can't see it in the workspace to get at it
[15:17] <sinzui> voidspace, abentley. It is generated. not pre-canned. We let juju make the jenv file. We update the version in it to ensure juju does what we and enterprises mean
[15:17] <voidspace> ah, I see
[15:17] <mgz> bodie_: see comments on review, one thing needs fixing and some other comments, then lets land
[15:17] <sinzui> voidspace, we tell users to share jenvs. we are
[15:17] <bodie_> cool
[15:17] <abentley> sinzui: We leave the .jenv entirely untouched.  It's the yaml that we tweak.
[15:18] <sinzui> I am tempted to do the lxc upgrade, then ask jenkins to run the test as usual
[15:19] <voidspace> sinzui: ok
[15:19] <bodie_> mgz, I agree about pulling out the yaml -- is there a place in the repo where test files could go?  there will be a charm actions yaml loader tested separately as part of dir (I think it was)
[15:20] <voidspace> can I get at the CI scripts? I'm reading the logs, but it looks like a lot of the work is in deploy_job.py
[15:20] <mgz> bodie_: it would be an improvement to just have them as top level variables so that's easy later, splits the test logic a bit but easier to pull apart later
[15:21] <mgz> voidspace: the branches should be public
[15:21] <voidspace> mgz: ok
[15:21] <mgz> voidspace: bzr branch lp:juju-ci-tools
[15:21] <voidspace> yep, just found it :-)
[15:22] <voidspace> mgz: thanks
[15:23] <bodie_> mgz, I moved them to local scope due to fwereade's comments here: https://codereview.appspot.com/94540044/diff/1/charm/actions_test.go#newcode21
[15:24] <mgz> bodie_: lets not go back and forth on that then :)
[15:24] <abentley> voidspace: Every juju action is dumped to stdout so you should be able to reproduce the script actions from the log output.
[15:24] <sinzui> abentley, voidspace jenkins failed again after the update
[15:25] <bodie_> there's probably a case to be made for either approach.  I'm personally kind of a fan of the way the gojsonschema tests work with external files, but in this case it's not really testing the schema as much as the YAML reader, which is simple enough
[15:25] <sinzui> oh, I forgot the mem constraint
[15:25]  * sinzui run manually with the constraint
[15:25] <voidspace> cannot initiate replica set
[15:25] <voidspace> so it is the problem with mongo
[15:25] <voidspace> and just as mysterious as last time we saw it apparently
[15:25] <rogpeppe> frankban: reviewed https://codereview.appspot.com/92700044
[15:25] <bodie_> okay, going to put my kid down for a nap, then into the salt mines with me!
[15:26] <mgz> lick lick?
[15:27] <sinzui> voidspace, where any of these mongo warning relevant to the failure http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/1371/console
[15:27] <frankban> rogpeppe: thanks
[15:27] <bodie_> mgz -- after I get these tweaks in shall I start digging towards State then?
[15:28] <bodie_> maybe start on a new branch to get dir and the loader landed
[15:28] <mgz> bodie_: yeah, I think so
[15:28] <mgz> we'll make sure this lands first :)
[15:29] <voidspace> sinzui: unknown config field. Shouldn't be.
[15:29] <voidspace> I'll look at the last successful build, see if those warnings are new.
[15:30] <voidspace> nope, those warning were there before
[15:30] <sinzui> voidspace, the warning is from a vestigial environments.yaml. I think I can remove it now, juju 1.18 doesn't need it. 1.16 did
[15:33] <sinzui> voidspace, abentley maybe a memory issue...this is the failure from my manual run. I recalled the good bootstrap command from bash history, then appended the mem=2G http://pastebin.ubuntu.com/7544723/
[15:34] <voidspace> I'll try that locally
[15:34] <voidspace> I didn't use the memory constraint
[15:35] <voidspace> although my VM only has 1G!
[15:35] <sinzui> machine has lots of memory
[15:35] <abentley> sinzui: Hmm.  I wouldn't have thought that had an effect.  Especially since mongo runs outside the lxc.
[15:35]  * sinzui tries again without mem=2G
[15:35] <sinzui> abentley, agreed
[15:36] <voidspace> nope, works
[15:36] <voidspace> for me
[15:36] <voidspace> if we can't figure out the difference we'll have to back out the replica set change
[15:36] <sinzui> abentley, I believe 1G should be adequate for our testing on lxc anyway
[15:36] <voidspace> I'm looking up that specific failure (cannot initiate replica set)
[15:37] <voidspace> natefinch: ^^^
[15:37] <voidspace> natefinch: the precise failure is consistent when run as a CI job
[15:37] <voidspace> natefinch: although effectively the same command run on the CI machine succeeds
[15:37] <voidspace> natefinch: the specific failure is "cannot initiate replica set"
[15:38] <voidspace> natefinch: so the replica set is the problem, although it's not obvious why
[15:38] <natefinch> mongo logs probably have a better message.
[15:39] <voidspace> that error implies that we have a mongo started *without a replica set* and then tried to add a replica set
[15:39] <voidspace> or we tried to add a non-empty mongo to a replica set
[15:40] <natefinch> it's the initiation which has to happen after it starts
[15:40] <voidspace> but we start mongo with the replset argument
[15:40] <natefinch> that's not initiation
[15:41] <voidspace> nope, but initiation will fail if the db isn't empty
[15:41] <sinzui> voidspace, abentley I bootstrapped again manually *without* the mem constraint and it failed. This is the relevant errors: http://pastebin.ubuntu.com/7544771/
[15:41] <perrito666> voidspace: you are missing a step there?
[15:41] <voidspace> natefinch: https://jira.mongodb.org/browse/SERVER-6294
[15:41] <natefinch> voidspace: I don'tb think that's true.
[15:42] <voidspace> natefinch: that's the closest I could find to a reference
[15:42] <voidspace> natefinch: it's local.* that needs to be empty
[15:42] <voidspace> perrito666: I'm sure I'm missing lots of step
[15:42] <natefinch> voidspace: ahh, yeah... I don't think that's the problem
[15:44] <natefinch> usually it's that mongo can't resolve the address that you gave it during initiate, or you don't have access to the admin database
[15:44] <voidspace> rebootstrapping from an existing jenv worked for me
[15:46] <voidspace> natefinch: should I back out the change to unblock CI?
[15:46] <voidspace> natefinch: without a way to repro it's going to be hard to re-introduce though
[15:47] <natefinch> what's the version of mongo on ci vs your vm?
[15:48] <voidspace> sinzui: can you check the mongo version on the CI machine for me please
[15:48] <voidspace> natefinch: I'm using 2.4.6 it looks like
[15:48] <sinzui> voidspace,  Installed: 1:2.4.6-0ubuntu5~ubuntu12.04.1~juju1
[15:49] <voidspace> sinzui: thanks
[15:50] <voidspace> natefinch: so looks like the same
[15:51] <natefinch> I really don't want to revert a change that seems to work correctly on all machines except CI :/
[15:51] <natefinch> especially without understanding why
[15:56] <natefinch> my guess is that the address we're putting into the replicaset information in mongo is somehow not resolvable
[15:56] <perrito666> voidspace: run that rs.config by hand by connecting with the client
[15:57] <perrito666> you might get something more useful that failed out of it
[15:57] <voidspace> perrito666: the only place it fails is on the CI machine which I don't have direct access to
[15:57] <voidspace> perrito666: what specific command are you suggesting, we can ask sinzui or abentley to run it
[15:58] <perrito666> voidspace: line 5 of http://pastebin.ubuntu.com/7544771/
[15:58] <perrito666> rs.initiate(daconfig) iirc
[16:01] <voidspace> so, attempt to manually re-initiate? From my hunting it looks like that error message we get is the full mongo error.
[16:02] <natefinch> yeah, all you really need is { members: [ { host: "<IP_ADDRESS>:37019" } ] }
[16:02] <voidspace> it's odd that  we're using a 10.0 address in that call to replicaSet.Config
[16:02] <natefinch> yeah
[16:02] <voidspace> 2014-05-29 15:21:41 DEBUG juju.worker.peergrouper initiate.go:34 Initiating mongo replicaset; dialInfo &mgo.DialInfo{Addrs:[]string{"<IP_ADDRESS>:37019"},
[16:03] <voidspace> Followed by:
[16:03] <voidspace> 2014-05-29 15:21:42 INFO juju.replicaset replicaset.go:52 Initiating replicaset with config replicaset.Config{Name:"juju", Version:1, Members:[]replicaset.Member{replicaset.Member{Id:1, Address:"<IP_ADDRESS>:37019", Arbiter:(*bool)(nil), BuildIndexes:(*bool)(nil), Hidden:(*bool)(nil), Priority:(*float64)(nil), Tags:map[string]string{"juju-machine-id":"0"}, SlaveDelay:(*time.Duration)(nil), Votes:(*int)(nil)}}}
[16:04] <natefinch> yeah, you have to dial using localhost in order to get mongo to let you call initiate
[16:04] <voidspace> I'm checking what address we use when it succeeds on my machine
[16:04] <wwitzel3> grabbing some food
[16:05] <voidspace> ah, except I'm only seeing INFO not debug here
[16:05] <natefinch> run with --debug
[16:05] <voidspace> thanks
[16:07] <voidspace> I see *no* mongo related output
[16:10] <natefinch> voidspace: oh, right, you don't actually get the output, you have to look at the logs under $HOME/.juju/local/log
[16:11] <voidspace> natefinch: my successful run uses 10.0 addresses too
[16:12] <natefinch> maybe it's just the CI machine can't connect to that IP/port
[16:12] <natefinch> although I don't know why it would be different for precise and trusty
[16:12] <voidspace> natefinch: I'm pretty sure that "local.oplog.rs is not empty" error is coming back from mongo
[16:13] <voidspace> nor why it would be different on *some* precise machines
[16:14] <natefinch> maybe the CI machine already has the database populated in a way that a normal machine would not?
[16:14] <voidspace> I'm grabbing coffee
[16:24] <perrito666> uh, cffee, good idea
[16:24] <mgz> even better with an o
[16:36] <rogpeppe> anyone know what our convention is for landing branches in github.com/juju ?
[16:36] <rogpeppe> i want to submit this PR: https://github.com/juju/testing/pull/6
[16:38] <sinzui> natefinch, voidspace there are no other mongos running on ci. I did check that because I found that had happened before
[16:38] <voidspace> right
[16:39] <sinzui> but maybe there is config left behind?
[16:39] <voidspace> I wonder if somehow artifacts are persisting between test runs on *that* mongo
[16:41] <voidspace> natefinch: perrito666: is there some step we can run at the beginning of CI to ensure the database is clean and there is no config / other artefacts left around?
[16:42] <rogpeppe> in fact, have we got any CI set up on the github repos?
[16:42] <voidspace> the failure indicates to me  that we're trying to initiate a non-clean repo
[16:42] <voidspace> rogpeppe: no idea. I know that's not helpful, but I'm not ignoring you :-)
[16:42] <rogpeppe> voidspace: thanks
[16:42] <natefinch> voidspace: if mongo's not running, you can just delete and recreate the folder that we use for mongo
[16:43] <natefinch> rick_h_: what's the process for landing stuff on github?
[16:43] <perrito666> natefinch: +1 restore does just that
[16:44] <natefinch> rogpeppe: I don't think we have CI on github right now (at least for the juju-core stuff)
[16:44] <rogpeppe> natefinch: ok, ta. i'll just rebase and push it then.
[16:44] <mgz> natefinch: what stuff?
[16:44] <rogpeppe> mgz: github.com/juju/...
[16:44] <mgz> all the little bits?
[16:45] <mgz> yeah, that's all botless
[16:45] <rogpeppe> mgz: yeah
[16:45] <rogpeppe> mgz: ok, thanks
[16:45] <natefinch> we should fix that
[16:45] <natefinch> especially since we're moving more and more stuff into its own repo
[16:45] <rogpeppe> mgz: pity we've lost that, but i'm guessing sinzui has plans for reinstating it
[16:45] <mgz> it's covered as part of juju-core
[16:46] <rogpeppe> mgz: it's going to be part of other pieces too
[16:46] <mgz> once you start depending on a broken rev, core will refuse the dep bump
[16:46] <rogpeppe> mgz: juju-core CI runs the github.com/juju tests ?
[16:46] <mgz> that still leaves go get etc borked as we saw yesterday
[16:46] <sinzui> my ideal bot wil do the squashing for us so that we don't need to worry that we loose conversations when commits are removed
[16:47] <rogpeppe> sinzui: my plan is to rebase-squash only at submit time
[16:47] <rogpeppe> sinzui: but i have a feeling that violates the "don't rebase after publishing" rule
[16:48]  * rogpeppe misses rietveldt already
[16:48] <sinzui> It does and github will delete conversations linked to the revisions
[16:48] <rogpeppe> sinzui: so is there any way we can a) keep the conversations and b) keep the revision history coherent ?
[16:48] <mgz> rogpeppe: squash on merge would
[16:49] <rogpeppe> mgz: that's what i was suggesting, i think
[16:49] <sinzui> rogpeppe, I see that homebrew is now making their own swashed pull request for each pull request I make. My conversation and commits are maintained, but they do not show up as merged.
[16:49] <mgz> sinzui: yeah, that's the upshot
[16:50] <mgz> no pull requests are ever really merged
[16:50] <rogpeppe> yeah, i can see that's the case. i can live with that, i think
[16:50] <rogpeppe> just so long as i can get from the revision history to the conversations, i think it's all ok
[16:51] <sinzui> rogpeppe, I think the bot can merge the approve branch, test, squash, commit, then add a comment naming the replacement commit when it closes the original pull request
[16:51] <rogpeppe> sinzui: i guess we'll need a convention to allow the bot to choose an appropriate commit message.
[16:51] <sinzui> yep
[16:52] <rogpeppe> sinzui: most recent commit (by, erm, some measure of "recent") with some keyword in the message might work
[16:52] <sinzui> +1
[16:54] <natefinch> question..... do we really need to squash?
[16:55] <natefinch> So like... yes, roger's PR has 4 revisions and if you don't squash, those 4 revisions all go on main...... who cares?
[16:55] <mgz> natefinch: not nessersarily, especially if everyone gets in the habbit of rebasing neatly before proposing
[16:55] <rogpeppe> natefinch: yes, i care
[16:55] <natefinch> mgz: sure
[16:55] <mgz> natefinch: mostly hurts with lots of small review comment fixes
[16:55] <voidspace> natefinch: so the mongo directory is defined as agentConfig.DataDir() + '/db'
[16:56] <voidspace> natefinch: where is the default location
[16:56] <rogpeppe> natefinch: sometimes i'll commit hundreds of times before proposing
[16:56] <rogpeppe> natefinch: with minute changes
[16:56] <voidspace> "/var/lib/juju"?
[16:56] <rogpeppe> natefinch: i don't want all of those commits to end up cluttering the main log
[16:57] <natefinch> voidspace: I think so, yeah
[16:57] <rogpeppe> voidspace: /var/lib/juju/<agent-tag>
[16:57] <voidspace> rogpeppe: natefinch: between CI builds is it safe to delete /var/lib/juju altogether?
[16:57] <natefinch> voidspace: it better be
[16:57] <rogpeppe> voidspace: it should be
[16:57] <voidspace> good
[16:57] <natefinch> brb
[16:58] <rogpeppe> voidspace: although CI shouldn't be touching /var/lib/juju at all
[16:58] <voidspace> sinzui: can you check if there's a /var/lib/juju on the CI machine - and preferably delete that at the start of the CI build
[16:58] <rogpeppe> voidspace: because CI may be running on a juju node
[16:58] <rogpeppe> voidspace: in fact, it probably will be
[16:58] <rogpeppe> voidspace: so that will kill the local juju agents, which is not a great thing
[16:58] <voidspace> rogpeppe: we're worried that db artefacts are what is causing bootstrap of local provider to fail *only* on the CI machine
[16:59] <voidspace> sinzui: hmmm... if jenkins is provisioned by juju then blowing the whole thing away is not a good idea
[16:59] <voidspace> we just want to delete the part created by the CI run
[16:59] <sinzui> voidspace, I was about to say I want to keep the machine and unit agents alive
[16:59] <voidspace> heh
[16:59]  * sinzui looks for cruft
[16:59] <voidspace> probably preferable
[17:00] <rogpeppe> it would be nice if CI never actually touched /usr/lib/juju
[17:00] <sinzui> voidspace, /var/lib/juju is not contaminated.
[17:01] <voidspace> damn
[17:01] <voidspace> sinzui: thanks
[17:16] <perrito666> bbiab
[17:24] <rogpeppe> g'night all
[17:24] <voidspace> rogpeppe: g'night
[17:46] <voidspace> I have to go, EOD
[17:46] <voidspace> natefinch: so, we still don't have a resolution for this issue :-(
[17:47] <voidspace> which sucks majorly
[17:47] <natefinch> voidspace: ug.... yeah, thanks for all your work on it
[17:47] <voidspace> heh
[17:47] <natefinch> I think I might have some time to actually look into it... not that I currently have a precise VM, but I can make one
[17:47] <voidspace> cool
[17:47] <voidspace> let me know of any progress you make
[17:47] <voidspace> g'night all
[17:48] <bodie_> nite
[19:07] <bodie_> I'm not following why this is still showing a conflict in dependencies.tsv (all the way at the bottom)
[19:07] <bodie_> https://code.launchpad.net/~binary132/juju-core/charm-actions/+merge/219926
[19:08] <bodie_> oh, god.  did I commit it with merge comments still in it?  -_-
[19:08] <mgz> bodie_: you need to actually merge trunk I think
[19:09] <bodie_> that's what I thought I did, heh
[19:09] <mgz> the last rev seems to only have one parent
[19:10] <mgz> just `bzr merge co:trunk`, resolve, commit, push, should be fine
[19:12] <bodie_> alright, why would bzr merge lp:juju-core not work?
[19:12] <bodie_> doesn't that refer to trunk?
[19:23] <perrito666> how expensive is to iterate a slice?
[19:28] <natefinch> perrito666: O(n) :)
[19:29] <wwitzel3> yeah, plain old iteration should be linear
[19:30] <perrito666> natefinch: nobody likes a smartass :p
[19:30] <natefinch> perrito666: it's just like iterating over an array in C, with some bounds checking that makes it minutely slower.  If you're doing the for n, val := range slice {    version, then it copies each value, too, but using a for x := 0; x < len(slice); x++ {  there's no copying until you access an index of the slice (obviously)
[19:30] <natefinch> perrito666: heh
[19:30] <wwitzel3> lol
[19:30] <perrito666> natefinch: tx, that was the answer I was looking for
[19:31] <perrito666> :)
[19:31] <natefinch> perrito666: a slice is just a struct with a pointer to a backing array, the length of the current slice, and the capacity of the backing array.  Iterating over it is just like iterating over the backing array.
[19:31] <perrito666> I was curious about how much copying was range doing
[19:32] <wwitzel3> I'd just use the syntax that expresses the idea in a more clear fashion
[19:32]  * perrito666 is not so happy with having to check if a string is in a slice
[19:33] <natefinch> 90% of the complaints about Go are "I have to write this loop where in my other language, the loop is hidden from my view"
[19:33] <perrito666> natefinch: well, off course
[19:33] <wwitzel3> at the end of the day it is all just typing and loops
[19:33] <perrito666> natefinch: I think the issue is that almost everyone trying this knows python
[19:34] <natefinch> if x in foo:
[19:34] <natefinch> yeah I know
[19:34] <perrito666> wwitzel3: and if err != nil, dont forget if err != nil
[19:36] <bodie_> mgz, nope, bzr merge co:trunk didn't do it for me.  Not a branch: "/home/bodie/go/src/launchpad.net/juju-core/.bzr/branches/master/"
[19:36] <bodie_> er, that's when I tried to merge co:master because I got that error for trunk
[19:36] <natefinch> perrito666: yep
[19:36] <bodie_> sorry this is taking so long, I've been doing bzr gymnastics
[19:36] <mgz> bodie_: er, are you using the same branching scheme as me?
[19:36] <bodie_> poorly
[19:36] <bodie_> I'm using cobzr
[19:36] <mgz> okay, you're not
[19:37] <mgz> cobzr people, how do you address trunk?
[19:37] <natefinch> there's too many different ways to do colocated branches in bzr (which is to say, there's two, and they both seem to have the same name)
[19:37] <mgz> well, three
[19:37] <mgz> one was an actual bzr plugin that did the right things, and got superceeded by support in 2.6
[19:38] <mgz> then there's the weird go thing that doesn't play well with anything...
[19:38] <natefinch> I thought that's what cobzr was?
[19:38] <natefinch> oh
[19:38] <natefinch> I don't know that third thing
[19:39] <bodie_> okay, so what I need to do is really simple
[19:39] <bodie_> and I thought I already did it...
[19:39] <bodie_> but now I've erased and re-checked-out my repo, and I'm not certain it will be normal
[19:39] <bodie_> going in circles and driving myself nuts
[19:40] <natefinch> perrito666: you're welcome to write a utils package that hasa function that takes a slice of strings and a string and returns a boolean that says whether the string is in the slice.  then you could do like strslice.Contains(list, value)
[19:40] <mgz> natefinch: what do you call trunk with cobzr?
[19:41] <perrito666> natefinch: I am really thinking it although I am a bit suspicious about the fact that is not something that is already there and widely used, so I presume there must be a decent reason
[19:41] <bodie_> I think bzr merge lp:juju-core worked (I don't have any conflicts in my dependencies.tsv, in the file) but in Launchpad it shows conflicts
[19:41] <natefinch> mgz: uh.... I use the built in support.... I think?
[19:41] <natefinch> mgz: I have a branch called trunk
[19:41] <mgz> bodie_: yeah, that's fine too
[19:41] <mgz> bodie_: what does `bzr status` say?
[19:41] <natefinch> mgz: I just use bzr switch -b foo to make a new colocated branch....  I think that's the built-in support, not cobzr, right?
[19:42] <mgz> natefinch: can be either..
[19:42] <natefinch> lol
[19:42] <mgz> the actual naming is what different (and confusing), which is what you need for merge
[19:42] <perrito666> natefinch: that depends on what does your bzr
[19:43] <perrito666> mgz: I have to point to the place where my bzr branches actually live with the full path
[19:43] <mgz> perrito666: you use tim's method, right?
[19:43] <bodie_> there's a conflict in deps
[19:43] <perrito666> mgz: I... am not sure
[19:43] <perrito666> I am using A method
[19:43] <perrito666> which might be tim's
[19:46] <bodie_> mgz, I merged dependencies.tsv, fixed the conflict, tried to commit, ran bzr resolve dependencies.tsv, committed, pushed, erased the core repo, go get'd juju-core, bzr branch charm-actions, bzr switch charm-actions, bzr pull --overwrite lp:~binary132/juju-core/charm-actions, lastly bzr merge lp:juju-core/dependencies.tsv
[19:46]  * mgz blinks
[19:46] <bodie_> heh
[19:47] <mgz> okay, your problem
[19:47] <mgz> you merge just the branch
[19:47] <mgz> not a file *in* the branch, that's a cherrypick
[19:47] <mgz> you *want* the actual revisions to resolve the conflict, not just the file contents
[19:48] <mgz> bzr merge lp:juju-core <- what you want
[19:48] <bodie_> I don't understand why since all I'm trying to do is grab the differences in that file that will cause issues and tweak it to match trunk plus my addition
[19:48] <bodie_> so you're saying grab all of trunk just to make sure everything is shipshape before I land the branch?
[19:49] <perrito666> bodie_: you are trying to git your bzr
[19:49] <bodie_> :'(
[19:49] <mgz> because with a cherrypick, you still have a split history
[19:49] <mgz> and the launchpad merge resolution plays it safe
[19:49] <mgz> if there's not a clean history merge, it throws it back for a real person to resolve
[19:50] <bodie_> so I have to merge the whole trunk in order to merge a single file?
[19:50] <bodie_> that doesn't seem sensible
[19:50] <mgz> you're not merging a single file
[19:50] <mgz> even git doesn't work like that, it's not cvs
[19:51] <bodie_> hrm
[19:52] <mgz> you can do the merge in other ways to make launchpad happy, but just merging trunk as a whole is fine
[19:52] <mgz> (you can rebase all your changes onto trunk if you like)
[19:53] <mgz> (and push --overwrite the branch)
[19:53] <bodie_> I doubt it'll conflict since my stuff doesn't touch other places
[19:54] <bodie_> but how would I rebase my changes onto trunk?
[19:55] <mgz> eg, `bzr switch trunk && bzr switch feature_redux && bzr merge -rancestor:trunk..branch:feature && bzr commit` or similar
[19:56] <mgz> using the rewrite plugin means you can keep your individual revisions if you like
[19:56] <mgz> -b on the second switch, the the revspec may not be quite right
[19:57] <mgz> then you bzr push --overwrite <whereever remote feature branch is>
[19:58] <bodie_> I see
[19:59] <bodie_> I think I'm gonna stick to the basics for the time being
[19:59] <bodie_> still having enough trouble with bzr, heh
[20:00] <bodie_> once I've merged trunk then I simply need to commit to finish the job, right?
[20:00] <bodie_> I've edited the conflicts out and bzr resolved them
[20:07] <bodie_> Okay, I committed it, and pushed up to my branch, and it still appears to have conflicts, which I expressly fixed
[20:07] <bodie_> so either Launchpad is lagging, or I'm going insane, or both
[20:07] <bodie_> okay, it was just lagging.  thank god
[20:11] <perrito666> bodie_: you might still be going insane
[20:11] <bodie_> haha, for sure
[20:11] <bodie_> mgz, I'm looking at the other comment now -- I think this may actually be a more significant problem than it appears
[20:11] <bodie_> or --
[20:12] <bodie_> yeah, I don't think we're hitting it.  that's supposed to be for schemas that don't adhere to the spec for JSON-Schema
[20:12] <bodie_> which are supposed to be caught by gojsonschema
[20:14] <natefinch> perrito666: btw, next on our plate is doing backup and restore the right way.  WIth the schema upgrades stuff getting taken over by Tim's team, we'll be working on that pretty soon.
[20:15] <perrito666> natefinch: sweet
[20:15] <perrito666> with luck we will be able to do that before it breaks again
[20:17] <natefinch> haha
[20:23] <bodie_> oh, mgz I recall why we're not testing that error -- william thought we shouldn't test gojsonschema in our tests
[20:23] <bodie_> I'll add a couple of edge cases
[20:23] <mgz> bodie_: I'm a little less worried about the coverage than I am the error being bogus, but it should be easy enough to do something there
[20:24] <bodie_> hm?  I'm not following
[20:24] <mgz> the error in the branch has two fmt operators and one arg given
[20:24] <bodie_> ah
[20:24] <bodie_> gotcha
[20:24] <bodie_> why would that not build?
[20:25] <bodie_> I fixed that, thought you meant something different
[20:25] <mgz> it does build, it just is pretty bogus
[20:25] <mgz> you get some junk in the error string
[20:26] <bodie_> oh, since it's a formatting string it's at runtime
[20:26] <bodie_> I see
[20:26] <bodie_> I meant why would that build
[20:26] <bodie_> thanks :)
[20:49] <bodie_> mgz, if you're still waiting for my branch to come in, it's because I may have found an error with gojsonreference
[20:49] <bodie_> getting a nil exception in my new test
[20:50] <mgz> bodie_: urk?
[20:53] <natefinch> that feeling when you accidentally reboot your laptop instead of the VM running on it
[20:55] <natefinch> EOD anyway
[20:55] <mgz> natefinch: oh yeah...
[20:55] <natefinch> night all
[20:55] <mgz> have a good evening
[21:03] <waigani> morning all
[21:05] <perrito666> waigani: sure, morning, why not
[21:05] <waigani> hehe
[21:13] <waigani> fwereade: are you still awake?
[21:27] <fwereade> waigani, heyhey
[21:27] <waigani> fwereade: hello!
[21:27] <fwereade> waigani, how's it going?
[21:27] <waigani> fwereade: I'm stumbling my way into understanding client/server api cmd
[21:28] <waigani> fwereade: what do you mean by bulk api call?
[21:28] <waigani> fwereade: I checked the api.txt docs, but couldn't see anything
[21:28] <fwereade> waigani, I mean taking an array of args, and returning an array of results
[21:29] <waigani> ah okay, that's all it means?
[21:29] <fwereade> waigani, pretty much, yeah
[21:29] <waigani> and what I did was not good because it had no args?
[21:29] <fwereade> waigani, it's inconvenient in some respects but not having it is more inconvenient
[21:29]  * fwereade looks at api.txt, and adds it to the list of things to fix
[21:30] <waigani> fwereade: maybe if you elucidate your reasoning in api.txt, I'm happy to read that later
[21:30] <fwereade> waigani, yeah, I'm worried I may have given offence, I was *seriously* pissed yesterday off to discover that horacio can't fix a bug he's working on cleanly because someone implemented *another* non-bulk call
[21:31] <waigani> I'm not offended, I don't understand - that's all
[21:31] <waigani> fwereade: ^
[21:32] <waigani_> fwereade: why does having a cmd that calls an api without args an issue?
[21:32] <waigani_> i think my connection is having a spaz
[21:32] <fwereade> waigani, the short version is: you can always call a bulk API with one arg, but you can't call a singular one with bulk args; and you have many more opportunities for optimizing bulk calls, that you just don't get if you have singular ones
[21:33] <fwereade> waigani_, and the reason that no-args is bad is because it encodes the assumption that the result will always be the same for everyone everywhere
[21:34] <waigani_> fwereade: but couldn't that be the case?
[21:34] <fwereade> waigani_, in the StateServerAddresses (or whatever it is) case, one might think "ehh, the set will always be the same, doesn't matter who's calling", right?
[21:34] <fwereade> waigani_, but this is not true, because the actual address one might use to access machine X may depend on where you're calling it from
[21:35] <fwereade> waigani_, if we're explicit about "what does the state server address list look like to machine-4?" we can accommodate that problem without having to change the API
[21:36] <waigani_> right
[21:36] <waigani_> so it's about allowing room to move in the  future
[21:36] <fwereade> waigani_, and when we're, I dunno, provisioning a whole bunch of machines, it's much more efficient to say "what will the state servers look like for machines 5, 6, 7, 8,9,..."
[21:37] <fwereade> waigani_, yeah: changing an API is a whole heap more hassle than changing an implementation
[21:37] <waigani_> so api calls should ALWAYS tag an args struct? Even if there are no args in the struct?
[21:37] <fwereade> waigani_, the meta-point is that the assumption about common sets of state servers has a character to it that I have grown sensitive to because that sort of assumption seems to end up wrong *disturbingly* often
[21:38] <fwereade> waigani_, I'm not sure there are any cases where there aren't any args: the closest I can come up with is getting environ info, because there's always one environ per conn
[21:39] <fwereade> waigani_, that still doesn;t feel to me like enough of a unique snowflake to be worth breaking convention for
[21:39] <waigani_> okay I get it
[21:39] <fwereade> waigani_, because I've also used apis in which singular/bulk are mixed apparently at random, and I'd really like us to be predictable :)
[21:40] <fwereade> waigani_, (and when I have it usually seems that they have fallen prey to exactly that class of assumption, and had t ofix it later, and it always just looks embarrassing ;))
[21:40] <waigani_> fwereade: is there a way of ensuring args is always passed?
[21:40] <fwereade> waigani_, heh, we probably could do something to our rpc package
[21:41] <waigani_> could save a lot of explaining ...
[21:41] <fwereade> waigani_, but we're carrying the weight of the original client api, designed by rog, who doesn't believe in bulk api calls, and we're not ready to retire it all yet
[21:41] <fwereade> waigani_, much though I may want to
[21:42] <waigani_> I'm missing something with your grudge about the state servers
[21:42] <alexisb> fwereade, what time is it for you?
[21:42] <fwereade> waigani_, the specific bug was that we want state servers' api tasks to connect to the local api for preference
[21:43] <fwereade> alexisb, eh, 11:45, but cath went to bed early leaving me with 2 g&ts to drink, I have to entertain myself somehow
[21:43] <waigani_> lol
[21:43] <waigani_> by trying to drum some sense into us newbies!
[21:44] <alexisb> fwereade, hehe, fair enough
[21:44] <fwereade> waigani_, it's much more sinister than that, I'm trying to turn you all into mental copies of me :)
[21:44] <waigani_> okay, keep trying please :)
[21:45] <fwereade> waigani_, the first cut at the bug was a bit of a hack -- it was looking up the state servers in the agent config, grabbingone of them for the port number, and replacing the list with localhost:port
[21:45] <fwereade> waigani_, and so I said "eww!" and started thinking how we could do better
[21:45] <fwereade> waigani_, and to be fair it's not entirely easy to do better
[21:46] <fwereade> waigani_, it's not smart to keep the other api servers secret and *always* just write localhost, because we want to remain open to machines being demoted but still coming back into the fold as viable deployment targets
[21:47] <fwereade> waigani_, so we do indeed want to store the complete set of state servers
[21:47] <waigani_> I assumed that is what so I would assumed StateServerAddresses would return
[21:47] <waigani_> the complete set of state servers
[21:48] <waigani_> ugh, let me type that again
[21:48] <waigani_> I assumed that is what StateServerAddresses would return
[21:48] <fwereade> waigani_, right -- but the best set of addresses for machine 2 to know about is not "m0.dns, m1.dns, m2.dns"
[21:49] <fwereade> waigani_, it's "m0.dns, m1.dns, *localhost*"
[21:50] <fwereade> waigani_, but you can only return tailored results like this if you know who's asking
[21:50] <waigani_> seems like two different functions to me
[21:50] <fwereade> waigani_, think broader
[21:51] <fwereade> waigani_, the address yu use to hit a particular machine depends on your own location
[21:51] <fwereade> waigani_, this is a very narrow example, but the general problem is much broader
[21:51] <fwereade> waigani_, think of state servers spread across a manual environment
[21:52] <waigani_> okay
[21:52] <fwereade> waigani_, 10.x addresses may or may not be valid, depending on where you're connecting from
[21:52] <waigani_> one set of state servers per environ?
[21:52] <waigani_> ha
[21:52] <fwereade> waigani_, the same 10.x address might refer to entirely different machines, according to two different clients
[21:52] <waigani_> yep, of course
[21:53] <waigani_> I'm stuck in web world where everything has a public IP
[21:53] <fwereade> waigani_, yeah, I've had a bit of difficulty adjusting myself
[21:53] <fwereade> waigani_, remember when computers never talked to one another at all? life was so easy :)
[21:53] <waigani_> private networks make the story  much more interesting
[21:54] <waigani_> lol
[21:55] <fwereade> waigani_, anyway, this is essentially anecdotal, but it's a case in which being explicit about the intended context of the result would have made life a lot easier for us, because it would have been a pure api-side fix
[21:55] <waigani_> okay cool so, the result of StateServerAddresses is always relative to the agent calling it, and that agent needs to be passed in as an arg
[21:55] <waigani_> or an identifier for the agent i should say
[21:55] <fwereade> waigani_, and once you're being explicit about the agent who's interested, you may as well implement the bulk call for the reasons discussed above
[21:55] <fwereade> waigani_, yeah
[21:56] <waigani_> sweet I think I get it :)
[21:56] <waigani_> time for a quick question about my branch?
[21:56] <fwereade> waigani_, ofc, it is a matter of certainty that there will be some APIs for which my insistence on bulk never does us a shred of good, and they really are only ever called with a single arg, and that arg always matches the authenticated entity
[21:57] <fwereade> waigani_, but I think the costs are worth bearing when weighed against the costs of the alternative ;)
[21:57] <waigani_> yep, like my bogus CurrentUserInfo
[21:58] <waigani_> Why not just enforce args?
[21:58] <waigani_> ensure that a struct is always passed, even if empty?
[21:58] <waigani_> ohh because of backwards compatibility
[21:59] <fwereade> waigani_, mainly hysterical raisins -- I'm not confident that we've ever been entirely without APIs-that-make-me-grumpy
[21:59] <fwereade> waigani_, if we can get to the point where we can, I will be happy, but we *do* have to carry the 1.18 api forever
[21:59] <fwereade> waigani_, well, 5 years, which is approximately equal to forever
[21:59] <waigani_> oh
[21:59] <waigani_> yeah true
[22:00] <waigani_> well, at least get this in the docs
[22:00] <fwereade> waigani_, anyway, yes, let's talk about your branch -- can I take 5 for a ciggie first please?
[22:01] <waigani_> of course (and another g&t, makes things much more fun)
[22:01] <fwereade> waigani_, yeah, there were plenty of ephemeral google docs around the time we were discussing it but the never made it into dev docs
[22:01] <waigani_> ping me when you're ready
[22:06] <fwereade> waigani_, back :)
[22:06] <waigani_> fwereade: cool
[22:07] <waigani_> fwereade: I've got two questions
[22:07] <waigani_> one practical the other just for understanding
[22:07] <thumper> o/
[22:08] <fwereade> thumper, heyhye
[22:08] <waigani_> fwereade: how do you authorise the api calls?
[22:08] <thumper> fwereade: want to catch up hangout?
[22:08] <thumper> fwereade: I have some points around connect
[22:08] <fwereade> waigani_, the facades get created with something that implements Authorizer, and you can ask that who's connected
[22:09] <fwereade> waigani_, that's the primary mechanism for keeping inappropriate clients' dirty hands off apis they shouldn't have access to
[22:09] <waigani_> fwereade: cool I'll look into that, as I didn't want to expose UserInfo to just anyone
[22:09] <fwereade> thumper, shortly, yes please
[22:09] <waigani_> fwereade: second why have a client side api?
[22:10] <waigani_> fwereade: why can't clients just call and get results from the server api?
[22:10] <fwereade> waigani_, I'm not quite sure what you're asking, but I think the answer is "because we're bad at naming things"
[22:10] <waigani_> right, yeah I'm not quite sure what I'm asking either
[22:11] <fwereade> waigani_, the Client facade is implemented on the server, but it's so named because it's intended for the use fof clients
[22:11] <waigani_> I get that, but you were talking about machine 2 having access to the api on localhost?
[22:11] <waigani_> I don't understand that?
[22:12] <fwereade> waigani_, if machine 2 is a state server, api clients on that machine should prefer to connect to the local api server rather than the remote one
[22:12] <fwereade> (s)
[22:12] <waigani_> oooh it's a state sever
[22:12] <fwereade> waigani_, if you're not a state server you have no choice but to connect to a remote one
[22:13] <fwereade> waigani_, sorry, yeah, that was the context that I never explicitly mentioned
[22:13] <waigani_> okay I'm done! Can I be a fly on the wall for the connect conversation?
[22:13] <waigani_> fwereade: thank you :)
[22:13] <waigani_> a little part of my brain feels a little less like me ;)
[22:14]  * fwereade cackles cheerfully
[22:14] <fwereade> thumper, ready now, please invite waigani_ too
[22:15] <thumper> waigani_: https://plus.google.com/hangouts/_/gwnzn2d4zfnezivhtfspwc2r3ma?hl=en
[22:55] <thumper> waigani: did you want to do a standup? it is just the two of us
[22:56] <bodie_> fwereade, mgz, looks like there's a corner case in gojsonschema where a "$schema" key not at the document root causes a nil exception
[22:56] <waigani> thumper: okay
[22:56] <waigani> thumper: I'm in the channel
[23:32] <waigani> thumper: how can I check if --format is used?
[23:33] <thumper> waigani: you can just check the formatter name
[23:34] <waigani> thumper: cool, got it thanks


 @RikMills Hi! Do you mind if I backport https://invent.kde.org/frameworks/kwayland/-/commit/70eb1df5a14c668879443a853069af750920035b to kinetic? It should fix qt5-ukui-platformtheme FTBFS.
 Sure 👍


[03:43] <jose> hey guys, I think now it's time to set !isitout to not yet
[03:43] <jose> !isitout
[03:43] <jose> oh, sorry, it's already done