[00:01] <thumper> fwereade_: around?
[00:02] <fwereade_> thumper, yeah, kinda
[00:02] <thumper> fwereade_: got time for a 5 min chat?
[00:02] <thumper> fwereade_: got a few quick questions
[00:02] <fwereade_> thumper, sure, would you start it please?
[00:02] <thumper> yep
[00:03] <thumper> fwereade_: https://plus.google.com/hangouts/_/096d99c30b8876a0dec1471a202468258e010074?authuser=0&hl=en
[00:13] <fwereade_> thumper, hmm: type StringSet map[string]bool
[00:13] <fwereade_> thumper, then you can just return StringSet{}
[00:13] <thumper> that doesn't give enough type hiding IMO
[00:13] <thumper> it exposes the map functions that I don't want there
[00:14] <fwereade_> thumper, fair enough
[00:14] <fwereade_> thumper, just a thought :)
[00:14] <thumper> thanks
[00:16]  * thumper afk
[00:59] <mramm> davecheney: just got back
[03:13] <bigjools> trying to keep up with core changes in the maas branch is hard - what do we need  to fix errors about missing MongoURL on machine config?
[03:43] <jtv> Hi there — anyone else getting this test failure for a nonexistent function, environs.Setenv()?
[03:44] <jtv> environs/tools_test.go:344: undefined: environs.Setenv
[03:46] <thumper> I know what that is...
[03:46] <thumper> but I don't get that error
[03:46] <thumper> Setenv is "exported" in export_test.go (I think)
[03:49] <bigjools> thumper: I get it too FWIW
[03:49] <thumper> hmm... I haven't tested with latest trunk
[03:49] <thumper> just yesterday :)
[03:50] <thumper> environs/export_test.go
[03:50] <thumper> var Setenv = setenv
[03:51] <jtv> Yes, the theory works.  Having some trouble with the practice.
[03:52]  * thumper had tests pass
[03:52]  * thumper pulls latest
[03:52] <thumper> and retries
[03:53] <thumper> ok, it passes for me on raring with tip of trunk
[03:53] <thumper> jtv: are you sure you are using tip? and have no changes?
[03:54] <jtv> I'm not sure of anything, really.  I'll see if I can run it in another configuration.
[03:55] <jtv> No change so far...
[03:55] <jtv> Ah!  Got it.
[03:55] <jtv> It passes when I run "go test launchpad.net/juju-core/environs"
[03:56] <jtv> —not when I run "go test ./environs"
[03:56] <jtv> So it must be the softlinking again.
[03:58] <bigjools> !
[03:59] <jtv> One test failure because of that difference in all of environs nicely hits the bitter spot: not enough to make you think there's a systemic problem with the way you're running the tests, enough to make you stop and look for problems in the actual code.
[03:59] <bigjools> jtv: what do you mean by softlinking?
[04:00] <jtv> My $GOPATH/src/launchpad.net/juju-core is softlinked to a branch.
[04:09] <davecheney> jtv: that'll screw you every time
[04:09] <jtv> Yes, especially with the feature branch now.  Can't really afford to colocate such different worlds.
[04:18] <bigjools> jtv: it's not that then, I don't do that
[04:19] <bigjools> jtv: I am using native colo, works very well
[04:38] <arosales> davecheney, let me know if you still hit the 20 compute limit on hp cloud
[04:38] <davecheney> arosales: just saw your mail
[04:38] <davecheney> will try again
[04:38] <arosales> davecheney, the 200 limit bump should apply to the juju-scale-test project
[04:39] <arosales> but as I learned things can be different than expected :-)
[04:39] <davecheney> third times' a charm
[04:40] <thumper> davecheney: []string(nil) is a nil slice? whereas []string{} is an empty slice?
[04:40] <davecheney> yes
[04:40] <thumper> hmm...
[04:42] <thumper> ok, my tests pass now
[04:42] <thumper> if you take params(values... string)
[04:42] <thumper> and don't pass anything in
[04:42] <thumper> you get a nil slice, not an empty slice
[04:43] <davecheney> yes
[04:43] <davecheney> normally this doesn't matter
[04:43] <davecheney> but gocheck cares
[04:44] <arosales> davecheney, :-)
[04:46] <davecheney> m_3: ping
[05:21]  * thumper proposes the hacking for the day
[05:22]  * davecheney listens
[05:22] <davecheney> thumper: i'll LGTM your proposal if yuou rename trivial to utils
[05:22] <davecheney> or util
[05:22] <davecheney> even
[05:23] <thumper> I didn't really want to do that until we agreed on a name :-|
[05:23] <thumper> but I do want to rename trivial
[05:23] <davecheney> that's my deal, take it or leave it
[05:23] <thumper> or kill it and move the content
[05:24] <thumper> :)
[05:24] <thumper> I can wait
[05:24] <davecheney> i'll also accept that
[05:24] <thumper> I'll propose another branch first thing monday to move / change the trivial package to util(s)
[05:25] <thumper> davecheney: I wanted a set to deal with the bootstrap fake series
[05:25] <thumper> which is now the top of the pipeline
[05:25] <davecheney> what is the CL again ?
[05:25] <thumper> CL?
[05:26] <thumper> for what?
[05:26] <thumper> it seems you can't add a prereq for something already proposed
[05:26] <davecheney> thumper: nope
[05:26] <thumper> oh well, friday calls, and warsaw's second law says time to stop :)
[05:27] <davecheney> fucking prereqs
[05:27] <thumper> davecheney: have a good weekend
[05:28] <davecheney> you too mate
[06:04] <rogpeppe> davecheney: hiya
[06:05] <rogpeppe> davecheney: i don't want to rename trivial to utils. we deliberately decided against utils as a name.
[06:06] <davecheney> i understand
[06:06] <davecheney> i still side with tim
[06:06] <davecheney> the only thing worse than having a utils package, is having two of them
[06:30] <rogpeppe> davecheney: i'm ok with a utils *directory*
[06:31] <rogpeppe> davecheney: which is what he's actually done
[06:31] <rogpeppe> davecheney: so utils/trivial, utils/cloudinit, etc
[06:31] <davecheney> that is gold plating it
[06:31] <rogpeppe> davecheney: i don't think so
[06:32] <rogpeppe> davecheney: the problem with a "utils" package is it becomes a huge grab-bag of random stuff
[06:32] <rogpeppe> davecheney: but that's not a problem if each thing is in its own package, and we just use the "utils" name to keep the root name space uncluttered
[06:33] <rogpeppe> davecheney: (see my recent comments on https://codereview.appspot.com/8672044/)
[06:33] <davecheney> rogpeppe: i feel that encourages not one utils package, but a forrest of them
[06:34] <rogpeppe> davecheney: i think that's ok - each package can be small and simple and targetted to what it needs to do. i suggest reserving the name for leaf dependencies which could be as well implemented outside juju-core.
[06:34] <rogpeppe> davecheney: so nothing that imports juju-core/log, for example
[06:35] <davecheney> sure
[06:35] <davecheney> we can have different opinions here
[06:58] <rogpeppe> davecheney: ping
[07:07] <m_3> davecheney: pong
[07:07] <rogpeppe> m_3: are you around for a very brief chat?
[07:08] <rogpeppe> m_3: i want to knock up a minimal version of the juju-wait tool and want to make sure i'm doing the right thing first
[07:08] <m_3> rogpeppe: really can't atm... about to board a plane
[07:08] <rogpeppe> m_3: :-) ok!
[07:09] <m_3> yikes... lemme see
[07:09] <rogpeppe> m_3: short story: juju-wait (machine|unit)
[07:09] <rogpeppe> m_3: waits for machine or unit to come into a stable state
[07:09] <m_3> yeah, sorry man... that's just too ambitious atm... I'm trying to see if we're past our account limit on hp in the few minutes before the flight
[07:09] <rogpeppe> m_3: exits with non-zero if it ended in an error state
[07:10] <rogpeppe> m_3: okeydokey
[07:10] <m_3> stable is one of "started, start-error, install-error" or the equiv?
[07:10] <rogpeppe> m_3: yup
[07:11] <rogpeppe> m_3: brings you to a state where you can query status and find out what's actually gone on.
[07:11] <m_3> rogpeppe: and then it'd be nice to actually get the error state easily from there
[07:11] <m_3> rogpeppe: ack right
[07:12] <rogpeppe> m_3: ok, i'll print the error state
[07:12] <rogpeppe> m_3: or perhaps i'll always print the final state
[07:12] <m_3> we can filter status to get the state of the thing we're waiting on, but filters would be cool again at some point
[07:12] <m_3> it'd be great to also get the final state
[07:13] <m_3> but shell exit codes are important
[07:13] <rogpeppe> m_3: agreed. i'm wanting this to take less than an hour though :-)
[07:13] <m_3> haha
[07:13] <m_3> nice
[07:13] <m_3> ok, yeah, and we can totally refine over time
[07:13] <m_3> just being able to wait for a set of states to be reached
[07:13] <m_3> that'll rock
[07:13] <rogpeppe> m_3: juju-wait machine [state....] ?
[07:14] <rogpeppe> m_3: waits for any of the given states to be reached?
[07:14] <m_3> by service instead?
[07:14] <rogpeppe> m_3: ah...
[07:14] <rogpeppe> m_3: that's more interesting. wait for *all* units in the service to reach the given state?
[07:15] <m_3> juju wait mysql "started | start-error"
[07:15] <m_3> or perhaps just a unit
[07:15] <rogpeppe> m_3: just a unit has more obvious semantics
[07:15] <m_3> that's all that's needed right now... `juju wait mysql/0 --state=...`
[07:16] <m_3> something along those lines
[07:17] <rogpeppe> m_3: juju wait mysql/0 'started|.*error' ?
[07:17] <rogpeppe> m_3: i.e. a regexp for the acceptable stages
[07:17] <rogpeppe> states
[07:17] <m_3> davecheney: I started 30 instances from ubuntu@15.185.162.247... might not have connectivity to wait them out and shut them down... please check on it in an hour or so if you can
[07:18] <m_3> davecheney: shut em down either way... then you can play if the numbers are up
[07:18] <m_3> rogpeppe: dude, that syntax would rock
[07:18] <rogpeppe> m_3: cool. that's also more trivial to do.
[07:18] <m_3> rogpeppe: that'd be great... probably all we'd need
[07:19] <rogpeppe> m_3: wonderful, just what i want hear
[07:19] <rogpeppe> m_3: just units for the time being, no machines or other things?
[07:19] <m_3> rogpeppe: right
[07:19] <rogpeppe> m_3: great
[07:19] <rogpeppe> m_3: thanks - that's very helpful!
[07:20] <m_3> rogpeppe: prob not worth the time to work up any other logical expressions of state ( ! & | )
[07:20] <m_3> rogpeppe: regexps'll be awesome
[07:20] <rogpeppe> m_3: juju wait -v mysql/0 '.*error'
[07:20] <rogpeppe> m_3: wait for anything *but* the given regexp
[07:20] <rogpeppe> m_3: analagous to grep -v
[07:21] <m_3> yup... but really we can add tha tlater
[07:21] <rogpeppe> m_3: ok, cool
[07:21] <m_3> rogpeppe: thanks!
[07:42] <davecheney> m_3: hey
[07:42] <davecheney> i was going to ask you about building that mongodb package
[07:42] <davecheney> but I figured it out from your instruciotns
[08:23] <dimitern> rogpeppe, fwereade_: looking for a critical eye on the log deuglifying CL - now with JUJU: and prefixes removed - https://codereview.appspot.com/8674043/
[08:23] <rogpeppe> dimitern: looking
[08:27] <rogpeppe> dimitern: reviewed
[08:28] <dimitern> rogpeppe: cheers
[08:29] <fwereade_> dimitern, please drop all the JUJU: crap
[08:29] <fwereade_> dimitern, not just JUJU
[08:29] <dimitern> fwereade_: I did, didn't I?
[08:29] <fwereade_> dimitern, ERROR jujutest blah command failed: BAM!
[08:29] <fwereade_> dimitern, ERROR command failed: BAM!
[08:30] <dimitern> fwereade_: so rogpeppe is suggesting to drop the "command" from there, do you agree?
[08:30] <dimitern> fwereade_: but leave the command name
[08:30] <fwereade_> dimitern, not necessarily -- IMO that's out of scope
[08:31] <fwereade_> dimitern, no, drop the command name too please
[08:31] <fwereade_> dimitern, none of the JUJU:... stuff needs to exist
[08:31] <dimitern> rogpeppe: agreed?
[08:31] <fwereade_> dimitern, rogpeppe: "command failed: %v" is a useful final thing to note, right?
[08:32] <dimitern> fwereade_: well, which command was that?
[08:32] <fwereade_> dimitern, the one you just ran
[08:32] <rogpeppe> fwereade_: i suppose so, although the command will print that anyway, i suppose. hmm, but maybe not to the log file
[08:32] <fwereade_> dimitern, I am not interested in catering to goldfishes ;p
[08:32] <rogpeppe> fwereade_: it was just the redundancy of "jujutest foo" and "command"
[08:33] <rogpeppe> fwereade_: FWIW i think that the final message printed by a failing juju command *should* be prefixed by the name of the command
[08:33] <rogpeppe> fwereade_: but not necessarily the log message
[08:33] <fwereade_> rogpeppe, and honestly I am not *very* interested in logging the CLI stuff -- I'd hope we'd have an Infof in supercommand, maybe, saying what we're running, and leave it at that
[08:34] <dimitern> ok, I'll drop both the "command" and the command name from the log message
[08:34] <fwereade_> rogpeppe, doesn't sound unreasonable
[08:34] <rogpeppe> fwereade_: yeah. the logging stuff is interesting from a CLI p.o.v. because it's what gets printed for --verbose/debug
[08:34] <fwereade_> dimitern, please just stick to the task as given ;p
[08:34] <rogpeppe> dimitern: if you drop the command name, you can leave "command"
[08:34] <fwereade_> rogpeppe, yeh, I see the job of log in a CLI context as feedback not logging IYSWIM
[08:35] <fwereade_> rogpeppe, dimitern: messing with "command failed" is out of scope
[08:35] <fwereade_> rogpeppe, dimitern: we discussed this on the lists and crafted it carefully so as not to piss away too much time
[08:35] <rogpeppe> fwereade_: +1
[08:36] <dimitern> fwereade_, rogpeppe: so finally, leave just "ERROR command failed: xyz" instead of "ERROR jujutest blah command failed: xyz" ?
[08:36] <rogpeppe> dimitern: yup
[08:42] <dimitern> ok, submitting with that change then
[08:48] <dimitern> fwereade_: I need a crash course talk for the constraints implementation for openstack :)
[08:52]  * TheMue happily discovered that the endpoints in relation keys are sorted, so the tests are not only "green by accident".
[08:58] <dimitern> rogpeppe: what happened yesterday with the SetProvisioned() issue? you said you found the problem, but didn't share
[08:58] <rogpeppe> dimitern: i was running into the incompatible tools issue
[08:59] <rogpeppe> dimitern: i was using an older client with uploaded tools
[08:59] <dimitern> rogpeppe: so your setup was flawed, not the code?
[08:59] <rogpeppe> dimitern: so it was creating the Machine in mongo without the new fields
[08:59] <rogpeppe> dimitern: so the assertion failed
[08:59] <rogpeppe> dimitern: yes, but...
[08:59] <dimitern> rogpeppe: right! I was beginning to get concerned
[09:00] <rogpeppe> dimitern: it was good because it made me aware of a new and quite subtle potential compatibility issue to watch out for
[09:00] <dimitern> rogpeppe: incompatible schema? it's not new i think
[09:00] <rogpeppe> fwereade_: have you seen this bug, BTW? https://bugs.launchpad.net/juju-core/+bug/1168154
[09:01] <rogpeppe> dimitern: it's *how* it's incompatible that's interesting
[09:01] <rogpeppe> dimitern: i had assumed that we could add fields without necessarily being incompatible
[09:01] <dimitern> rogpeppe: ah, right :)
[09:02] <rogpeppe> dimitern: and that can be true, but not if we assume that they start life as set.
[09:03] <dimitern> rogpeppe: this opens a potentially vast can of worms in the code, where we need to care about fields not being there, when they should be, all kinds of failing asserts..
[09:03] <dimitern> rogpeppe: and i suppose that was the reason for the log file being so huge after 2h?
[09:03] <rogpeppe> dimitern: i think it's only a problem when we're asserting that something is an empty string
[09:04] <rogpeppe> dimitern: yeah, the provisioner was constantly falling over and being restarted
[09:05] <dimitern> rogpeppe: how about asserting on non-empty field, which isn't there?
[09:05] <rogpeppe> dimitern: i don't think that's a problem
[09:05] <dimitern> rogpeppe: cool
[09:05] <rogpeppe> dimitern: the assertion will fail as it did in our example yesterday
[09:06] <dimitern> rogpeppe: but it's essentially the same failure as if the field was there, but with a different value
[09:07] <rogpeppe> dimitern: yes, which is fine. if we assert that field=="value" then we don't care about the difference between field=="" and field==nil.
[09:14] <rogpeppe> fwereade_: you might've missed my comment: have you seen this bug? https://bugs.launchpad.net/juju-core/+bug/1168154
[09:14] <rogpeppe> fwereade_: it's a bit concerning, but may be trivial to fix
[09:15] <fwereade_> rogpeppe, responded, I'm not certain there's a juju problem there so much as a charm problem
[09:17] <dimitern> fwereade_: and how about a quick chat about openstack constraints?
[09:17] <rogpeppe> fwereade_: ah, interesting. what charm hooks need to run before the unit can be destroyed?
[09:18] <fwereade_> rogpeppe, broadly speaking, once it starts it expects to pass through install, config-changed, start before top and suicide
[09:18] <fwereade_> s/top/stop/
[09:18] <rogpeppe> fwereade_: ah, i'd forgotten there was a stop hook
[09:19] <fwereade_> dimitern, sure
[09:19] <fwereade_> dimitern, would you start a hangout please?
[09:20] <rogpeppe> fwereade_: yeah, i think that if install or start fail, we should allow unit removal without resolving the error.
[09:21] <rogpeppe> fwereade_: i wonder if actually we should allow the stop hook to run regardless.
[09:21] <dimitern> fwereade_: https://plus.google.com/hangouts/_/143d8b05982bc269466e8bb2402d68e8d0018523?authuser=0&hl=en
[09:24] <rogpeppe> fwereade_: the reason for the charm failing is that it tried to do "apt-get install -y --force-yes python-shell-toolbox" which failed (error: Unable to locate package python-shell-toolbox)
[09:57] <fwereade_> rogpeppe, sorry, could have sworn I sent a reply
[09:58] <rogpeppe> fwereade_: a reply to the bug? you did.
[09:58] <fwereade_> rogpeppe, that hook failure sounds like a charm problem rather than a juju problem
[09:58] <rogpeppe> fwereade_: yup
[09:58] <fwereade_> rogpeppe, ok, so I'm not too bothered there
[09:58] <rogpeppe> fwereade_: but i think it should be possible to destroy a failed unit
[09:58] <fwereade_> rogpeppe, unless we're deploying it on the wrong series or something and killing it that way?
[09:59] <rogpeppe> fwereade_: because calling "resolved" on it might lead to worse problems
[09:59] <fwereade_> rogpeppe, like what?
[10:00] <rogpeppe> fwereade_: like subsequent hooks fail or behave badly because the previous hook has failed but been "resolved" without any actual resolution
[10:00] <fwereade_> rogpeppe, then if you must you can painstakingly `resolved` your way through it to destruction
[10:00] <rogpeppe> fwereade_: also, if i call destroy on a unit that's in an error state, i think it's reasonable to assume that i want to kill it, not let it carry on.
[10:01] <rogpeppe> fwereade_: yeah, i think that's wrong - lots of work for no gain.
[10:01] <fwereade_> rogpeppe, STRONGLY disagree
[10:01] <fwereade_> rogpeppe, you might want to kill it but you still have to resolve it and walk it through an orderly shutdown
[10:01] <fwereade_> rogpeppe, fancy features for skipping that need careful thought
[10:02] <rogpeppe> fwereade_: this is particularly true for install/start hook failures
[10:02] <rogpeppe> fwereade_: i don't mind too much about later failures
[10:03] <fwereade_> rogpeppe, so long as there's a clear boundary I'm ok extending the window
[10:03] <rogpeppe> fwereade_: if a charm has failed to install, i want to be able to blow it away, and i can't see any particular reason why we shouldn't allow that
[10:03] <fwereade_> rogpeppe, but not now
[10:03] <fwereade_> rogpeppe, there is a path to resolution
[10:03] <fwereade_> rogpeppe, it may suck but it exists
[10:03] <rogpeppe> fwereade_: fair enough
[10:05]  * fwereade_ bbiab
[10:05] <rvba> fwereade_: we've fixed most of the problems you pointed out… we're landing the MAAS provider feature branch right now.
[10:05] <jtv> All the important ones are fixed.
[10:12] <jtv> fwereade_: feature branch has landed...  see the MP for another note, on your comment #2 — if it's weird, it's EC2's kind of weirdness so I don't think it needs changing right now.
[10:23]  * dimitern bbiab
[10:28]  * TheMue loves merging conflicts *gnarf*
[11:04] <fwereade_> rogpeppe, ping
[11:04] <rogpeppe> fwereade_: pong
[11:04] <fwereade_>             assertNothingHappens(c, upgraderDone)
[11:04] <fwereade_> rogpeppe, in jujud/upgrader_test.go
[11:04] <rogpeppe> fwereade_: i'm just fixing that exact code
[11:04] <rogpeppe> fwereade_: it's crack
[11:04] <fwereade_> rogpeppe, fucking tell me about it
[11:04] <rogpeppe> fwereade_: it's nearly done
[11:05] <rogpeppe> fwereade_: it was from before i knew that interlinked table-driven tests were an anti-pattern
[11:05] <fwereade_> rogpeppe, I am a little surprised that you are doing it given that I said I would, though
[11:05] <rogpeppe> fwereade_: i said i'd fix the upgrader tests
[11:07] <fwereade> rogpeppe, I said, not sure if you saw: I am a little surprised that you are doing it given that I said I would, though
[11:07] <rogpeppe> [12:05:56] <rogpeppe> fwereade_: i said i'd fix the upgrader tests
[11:07] <rogpeppe> fwereade: to be compatible with both old and new dev-versions
[11:08] <rogpeppe> fwereade: and you said "yes please" AFAIR
[11:08] <rogpeppe> fwereade: 'cos i knew they'd be a hassle
[11:08] <fwereade> rogpeppe, as I recall you said they needed to be fixed, and I said I knew, and that they fit well with what I was currently doing
[11:08] <rogpeppe> fwereade: oh, crossed wires, sorry
[11:09] <rogpeppe> fwereade: how far down the road are you?
[11:09] <rogpeppe> fwereade: i've unfucked the tests in principle; i just need to get them to pass now.
[11:09] <fwereade> rogpeppe, I have spent about 12 hours straight unfucking upgrades
[11:09] <fwereade> rogpeppe, and I have a green build
[11:09] <rogpeppe> fwereade: oh, ok, cool./
[11:10] <rogpeppe> fwereade: i've only spent the last 2.
[11:10] <fwereade> rogpeppe, and I am on a sanity pass through
[11:10] <rogpeppe> fwereade: assertNothingHappens could never be triggered
[11:10] <rogpeppe> fwereade: because the channel never gets sent to
[11:10] <rogpeppe> fwereade: i think it probably did in an earlier incarnation which changed.
[11:10] <fwereade> rogpeppe, however I did just spot that that can't possibly work, yeah
[11:11] <rogpeppe> fwereade: i changed it to: http://paste.ubuntu.com/5701129/
[11:11] <fwereade> *yoink*
[11:12] <rogpeppe> fwereade: good word :-)
[11:21] <dimitern> mramm: ping
[11:23] <TheMue> *hmpf* test fails after merge, but sure it will be easy
[11:40] <TheMue> Bingo
[11:50] <TheMue> fwereade: could you pls take a look at https://codereview.appspot.com/8705043. it's still wip, i will add more test scenarios (multiple relations, peer relations), but i would like a feedback about the current approach by you
[11:50] <fwereade> TheMue, will do shortly
[11:50]  * TheMue just has been called for lunch, bbiab
[11:50] <TheMue> fwereade: great, thx
[12:49] <dimitern> the trunk is now broken
[12:49] <dimitern> environs/maas/environ.go:7:2: import "launchpad.net/gomaasapi": cannot find package
[12:50] <TheMue> dimitern: did you go get it?
[12:50] <rvba> dimitern: we just merged the MAAS provider.  You need to get the lib gomaasapi.
[12:50] <dimitern> TheMue: I tried go get launchpad.net/gomaasapi/...
[12:51] <dimitern> and it reported: # launchpad.net/gomaasapi/example
[12:51] <dimitern> ../gomaasapi/example/live_example.go:45: not enough arguments in call to gomaasapi.NewAuthenticatedClient
[12:51] <dimitern> go get launchpad.net/gomaasapi (w/o /... works) though
[12:51] <TheMue> dimitern: ouch, so gomaasapi is broken and the trunk fails as a result of this
[12:52] <rvba> dimitern: let me look into it…
[12:52] <dimitern> rvba: now running go build ./... && go test ./... in juju-core/
[12:53] <dimitern> rvba: but the same fails inside gomaasapi with the error above
[12:54] <rvba> dimitern: I'm on it.  We updated something in gomaasapi but forgot to update the 'live_example.go' file.
[12:54] <dimitern> rvba: cheers
[12:55] <dimitern> rvba: always run "go build ./... && go test ./..." successfully before submitting please
[12:55] <dimitern> rvba: juju-core tests pass
[12:55] <rogpeppe> lunch
[12:55] <rvba> dimitern: we did got the tests to pass before merging.
[12:56] <dimitern> rvba: I mean in the dependencies as well, like gomaasapi
[12:57] <dimitern> so juju-core trunk is not broken after all, sorry
[12:59] <mramm> dimitern: pong
[13:00] <dimitern> mramm: sorry, I wanted to ask about the swap days after US flights
[13:00] <mramm> sure
[13:00] <dimitern> mramm: but I figured I can ask in oakland :)
[13:00] <mramm> cool
[13:01] <dimitern> mramm: anyway, I updated the calendar with my holiday leave in june (10-25) and for europython in july (1-5), filed swap days, etc. in cadmin
[13:02] <mramm> dimitern: great -- I saw the calendar updates
[13:02] <mramm> but will login to cadmin and approve stuff
[13:03] <dimitern> mramm: cheers, actually probably jam needs to approve these still, but anyway
[13:04] <mramm>  right!
[13:15] <TheMue> mramm: btw, during oakland we have a national holiday. i'll take it together with the swap days and two of my holidays of last year in the week after oakland.
[13:17] <mramm> sure
[13:20] <rvba> dimitern: the fix has landed.  I'll also land a fix to make sure that kind of breakage does not happen again (i.e. to make sure that the content of examples/ [which is not tested by the unit tests] compiles).
[13:21] <dimitern> rvba: that's good, but now I see another error:
[13:21] <dimitern> # launchpad.net/gomaasapi/templates
[13:21] <dimitern> templates/source_test.go:11: undefined: GomaasapiTestSuite
[13:21] <rvba> dimitern: that's fixed in my next branch :)
[13:21] <dimitern> rvba: ah, cool
[13:23] <TheMue> dimitern: hehe, that's real wip
[13:41] <rvba> dimitern: all fixed now.
[13:42] <dimitern> rvba: indeed, thanks!
=== wedgwood_away is now known as wedgwood
[14:01] <dimitern> i still can't find the kanban g+ link :(
[14:02] <dimitern> mramm: can you send it please? I'll add it to my calendar manuallt
[14:02] <dimitern> ah! found it! sorry
[14:02] <mramm> https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083
[14:41] <fwereade> TheMue, I'm not to sure about https://codereview.appspot.com/8705043/
[14:41] <fwereade> TheMue, where did you get that data format from?
[14:44] <fwereade> rogpeppe, dimitern: the upgrade-juju stuff is here: https://codereview.appspot.com/8663045/
[14:45] <rogpeppe> fwereade: woo!
[14:45] <TheMue> fwereade: by daves code and my interpretation of the py code
[14:45] <TheMue> fwereade: i have to step out for i thin 1h. will ping you then again.
[14:46]  * fwereade now has to dust off the provision-time changes and see how badly they rotted in the last day
[14:46] <rogpeppe> fwereade: and in return, juju-wait: https://codereview.appspot.com/8710043
[14:46] <rogpeppe> dimitern: ^
[14:46] <dimitern> fwereade: will take a look a bit later
[14:46] <dimitern> rogpeppe: and at yours too
[14:46] <rogpeppe> dimitern: ta!
[14:47]  * dimitern needs to think a bit, so going for a short run - bbi30m
[15:15] <jtv> Would anyone be interested in having a makefile?  There are a few advantages that come from convenience...  Suggestion is at https://codereview.appspot.com/8711043
[15:29] <rogpeppe> jtv: +0; i don't think i'd ever use it.
[15:29] <rogpeppe> jtv: but i wouldn't mind it being around
[16:27] <rogpeppe> fwereade: any chance of a review of https://codereview.appspot.com/8710043/ ?
[16:27] <rogpeppe> fwereade: i'm a fair way into your upgrade-juju review, BTW
[16:27] <dimitern> rogpeppe: i'm on it now
[16:27] <rogpeppe> dimitern: cool, thanks
[16:41] <dimitern> rogpeppe: reviewed
[16:41] <rogpeppe> dimitern: ta!
[16:53] <dimitern> fwereade: your internet connection sure is flaky today
[17:05] <rogpeppe> fwereade: you've got a first round of review comments
[17:08] <rogpeppe> fwereade: hmm, what's our rationale for not letting agent version change in config again?
[17:18] <fwereade> rogpeppe, it's just a way to mess up the upgrade process afaict
[17:18] <rogpeppe> fwereade: ah, of course.
[17:19] <fwereade> rogpeppe, having no way except the approved one to change it feels like a win to me
[17:19] <rogpeppe> fwereade: might be good to add a comment there
[17:19] <rogpeppe> fwereade: +1
[17:19] <fwereade> rogpeppe, definitely
[17:19] <rogpeppe> fwereade: i *knew* there was a good reason!
[17:19] <fwereade> rogpeppe, sorry, btw, I need to stop for a while, I don't think I'll manage to finish it today
[17:19] <rogpeppe> fwereade: ok
[17:19] <fwereade> rogpeppe, if I do it'll be late
[17:19] <rogpeppe> fwereade: sure
[17:20] <rogpeppe> fwereade: i need to stop soon too
[17:20]  * fwereade strikes out in search of pizza
[17:20] <rogpeppe> fwereade: hopefully i'll get to the end of your review
[17:20]  * rogpeppe quite fancies pizza
[17:20] <rogpeppe> fwereade: have a great weekend!
[17:30] <dimitern> fwereade: reviewed as well
[17:31] <dimitern> i have to stop
[17:31] <dimitern> happy weekends everyone!
[17:48] <rogpeppe> m_3: ping
[17:48] <rogpeppe> m_3: if you're around at some point, please could you take a look at https://codereview.appspot.com/8710043/ and see if it looks like something you could use
[17:51] <rogpeppe> right, that's me done
[17:51] <rogpeppe> g'night all and happy weekends too
=== deryck is now known as deryck[lunch]
=== BradCrittenden is now known as bac
[19:29] <m_3> [6~[6~/win 2
[19:31] <TheRealMue> <7nick TheMue
=== TheRealMue is now known as TheMue
=== deryck[lunch] is now known as deryck
=== arosales_ is now known as arosales
=== wedgwood is now known as wedgwood_away