[00:08] <jhobbs> how can I enable trace logging for golxc when using juju?
[00:29] <wallyworld> jhobbs: juju set-env logging-config="<root>=INFO;unit=DEBUG;golxc=TRACE"
[00:29] <wallyworld> that's after a system is running
[00:29] <wallyworld> can also specify at bootstrap using --logging-config="blah"
[01:01] <cherylj> Can I get a review for my file handle bug fix?  http://reviews.vapour.ws/r/1740/
[01:26] <thumper> cherylj: shipit
[01:27] <cherylj> thanks, thumper!
[01:37] <davecheney> thumper: so i'm trying to fix a race in github.com/juju/juju/apiserver_test.(*pingerSuite).TestAgentConnectionDelaysShutdownWithPing()
[01:37] <davecheney> and i'm suspecting that apiserver.Pinger is not actually used
[01:37] <davecheney> two qestions
[01:37] <davecheney> 1. should I make a bug for each of these races
[01:37] <davecheney> 2. can I just delete apiserver.Pinger ?
[01:38] <davecheney> oh, i see how it's used
[01:38] <davecheney> ok
[01:51] <natefinch-afk> it's amazing how little time it takes writing in a language with exceptions to remind me why I hate them
[01:54] <axw_> anastasiamac: I ignored your "not ready for review", and reviewed ;)
[01:55] <axw_> anastasiamac: mostly looks good anyway
[01:55] <anastasiamac> axw_: oh! the headache ...
[01:55] <anastasiamac> axw: :D
[01:55] <anastasiamac> axw: it was marked this way as it does not work and m using the wrong glue
[01:55] <anastasiamac> axw: i think
[01:56] <anastasiamac> axw: tyvm for review... i m fixing it all now anyway :D
[01:56] <axw> anastasiamac: oh? it looked like it would work
[01:56] <axw> nps
[01:56] <anastasiamac> axw: nuh... it would not and it does not link properly... m going to hijack ian after ur 1:1 and nail this PR :D
[01:57] <wallyworld> natefinch: i have the opposite - amazing how using Go and putting if err != nil {return err} EVERYWHERE makes me miss exceptions so much
[01:59] <natefinch> wallyworld: my current complaint is that anything can fail, and you have no idea it can until it does.  And having the real code in your function be wrapped in 3 levels of indented try's and 20 lines of exception handling at the end... . and then you have the exception handling *inside* your except blocks, which if you forget, then you mask the original error....
[01:59] <wallyworld> natefinch: i guess it's like anything - it can be done nicely or poorly :-)
[02:00] <natefinch> wallyworld: I find it a lot easier to do error returns nicely... plus then if your function can fail, it's right there in the function signature.
[02:02] <natefinch> meanwhile, I think python's function-scoped variables is screwing me somehow
[02:02] <wallyworld> natefinch: true but what tends to happen is that we err != nil retrun err and just ignore the error
[02:04] <natefinch> wallyworld: that's not really any different than just letting an exception fly
[02:05] <wallyworld> natefinch: true, but doing exceptions is far less useless boilerplate
[02:05] <natefinch> wallyworld: is it? http://pastebin.ubuntu.com/11275221/
[02:06] <natefinch> at least with error returns the code paths are 100% straight forward if statements... not this convoluted jumping around in the code.
[02:07] <wallyworld> natefinch: just in meeting, will look in a bit
[02:07] <natefinch> wallyworld: np
[02:09] <natefinch> someday I'll finish up my blog post about why exceptions are evil.... maybe when all the kids are in school finally.
[02:12] <natefinch> anyone good at python want to help me out with figuring out why the wrong exception is being printed from this code?  http://pastebin.ubuntu.com/11275221/
[02:13] <natefinch> something in lines 19-24 throwing an exception, and then dump_env_logs on line 29 is throwing....  line 34 should be raising e, not e2, right?    Because right now, line 39 is logging e2 somehow.
[02:15] <natefinch> I added the try/catch around the dump_env_logs in order to try to keep that exception from masking the real problem... but somehow line 33 is logging the exact same error as line 39
[02:19] <natefinch> thumper: ^
[02:20] <natefinch> afk a bit
[02:24] <thumper> natefinch-afk: would really help to see the stack trace
[02:25] <axw> wallyworld: sorry, didn't want to miss my delivery
[02:25] <wallyworld> axw: np, we were finished anyway
[02:25]  * axw goes to play with new modem
[02:25] <wallyworld> enjoy
[02:30] <natefinch> thumper: full code (for correct line numbers): http://pastebin.ubuntu.com/11275530/      stack traces: http://pastebin.ubuntu.com/11275558/
[02:31] <thumper> natefinch: what are you expecting?
[02:36] <natefinch> thumper: I'm expecting that the raise on line 197 is going to raise e (from line 186) and it seems to be raising e2.
[02:38] <thumper> If no expressions are present, raise re-raises the last exception that was active in the current scope.
[02:38] <thumper> e2 was the last exception in the current scope
[02:39] <thumper> if you explicitly want e, go 'raise e'
[02:39] <natefinch> won't that screw up the stack trace of e?
[02:40] <thumper> not sure
[02:40] <thumper> try it
[02:41] <natefinch> it does
[02:41] <natefinch> that seems amazingly broken.
[02:42] <natefinch> tiny repro case: http://pastebin.ubuntu.com/11275739/
[02:44] <natefinch> (pay no attention to my tabs instead of spaces.... wrote it before I saved, so my editor didn't know to convert my tabs into spaces)
[03:01] <natefinch> I guess the solution is - you have to put that cleanup code in a separate function.
[03:01] <thumper> natefinch: yeah, I was just writing that out
[03:01] <thumper> had the same thought
[03:02] <thumper> make the second exception live in a different scope
[03:02] <natefinch> which is not horrible, it's just surprising
[03:02] <thumper> python scopes != indentation level
[03:02] <natefinch> yeah
[03:02] <davecheney> http://reviews.vapour.ws/r/1762/
[03:02] <natefinch> I knew the function-level scope was screwing me somehow
[03:15] <menn0> thumper: so jam caught me late last night and wanted one more improvement to the txn pruning work.
[03:15] <menn0> thumper: so here it is: http://reviews.vapour.ws/r/1763/
[03:16] <thumper> menn0: oh?
[03:16] <menn0> thumper: he wanted historical stats to be kept. which is probably a good idea.
[03:17] <menn0> thumper: especially given that pruning is quite infrequent now and so you won't see much in the logs once they get rotated.
[03:17]  * thumper nods
[03:19] <menn0> thumper: so review pls? :)
[03:19] <thumper> menn0: ack, was just reviewing davecheney's one
[03:19] <menn0> thumper: cheers
[03:20] <menn0> thumper: does your switch PR need another review?
[03:20] <thumper> menn0: yeah
[03:20] <menn0> thumper: k i'll have a look at that
[03:21] <thumper> menn0: does the txn package use juju/errors yet?
[03:21] <menn0> thumper: no, that's why i didn't introduce it
[03:21] <menn0> thumper: is it supposed to?
[03:21] <thumper> fair enough... for now,
[03:21]  * thumper shrugs
[03:21] <thumper> probably one day
[03:22] <menn0> thumper: I almost started using it but then noticed it wasn't used so thought that might have been on purpose to reduce coupling or something
[03:22] <menn0> it should probably use it
[03:36] <davecheney> https://github.com/juju/juju/pull/2402
[03:40] <axw_> wallyworld: would you mind taking a look at https://github.com/go-amz/amz/pull/50 for me?
[03:40] <wallyworld> sure
[03:43] <wallyworld> axw_: haven't looked yet, just finishung with anastasia, will look real soon
[03:43] <axw_> wallyworld: no worries
[03:55] <menn0> thumper: is it possible for a system and an env to have the same name?
[03:56] <thumper> yes
[03:56] <thumper> normally when you bootstrap
[03:56] <thumper> of have access to the initial environment
[03:56] <menn0> thumper: so how does switch tell the difference?
[03:56] <thumper> menn0: it doesn't, environments can be used as systems
[03:56] <menn0> right
[03:56] <thumper> but systems can't be used as environments
[03:57] <menn0> ok
[03:57] <natefinch> wait, what's a system?
[03:57] <thumper> so if you have access to the environment "test" and system "test", then it will always use the environment
[03:57] <natefinch> is that the base environment that all the sub-environments run on top of?
[03:57] <thumper> natefinch: kinda
[03:57] <menn0> could it be possible for someone to shoot themselves in the foot and name the non-initial env with the same name as another env or system?
[03:57] <thumper> natefinch: the word we were told to use
[03:57] <thumper> was server, now it is system
[03:58] <thumper> as it could be more than one server...
[03:58] <thumper> ha and all that
[03:58] <menn0> thumper: ^^^
[03:58] <menn0> (my Q a few lines back)
[03:58] <natefinch> thumper: makes sense
[03:58] <thumper> menn0: no, as the configstore treats that as an error
[03:59] <thumper> configstore has tests for all that
[03:59] <menn0> thumper: ok cool. just checking that this has been considered.
[03:59] <thumper> :-)
[04:12] <aisrael> alexisb: Here's the bug I mentioned the other day that's causing juju to hang after upgrading 1.24 betas: https://bugs.launchpad.net/juju-core/+bug/1457728
[04:12] <mup> Bug #1457728: `juju upgrade-juju --upload-tools` leaves local environment unusable <juju-core:New> <https://launchpad.net/bugs/1457728>
[04:12] <axw> wallyworld: please see my reply about non-contiguous sequence numbers in request params
[04:12] <wallyworld> ok
[04:13] <wallyworld> axw: sounds good
[04:13] <axw> wallyworld: ta
[04:21] <menn0> thumper: one line review pls http://reviews.vapour.ws/r/1765/
[04:21] <menn0> thumper: forgot to say... review done
[04:21] <menn0> thumper: for the switch change
[04:22] <mup> Bug #1457728 was opened: `juju upgrade-juju --upload-tools` leaves local environment unusable <juju-core:New> <https://launchpad.net/bugs/1457728>
[04:33] <menn0> wallyworld or axw: one line review pls? http://reviews.vapour.ws/r/1765/
[04:34] <mup> Bug #1457728 changed: `juju upgrade-juju --upload-tools` leaves local environment unusable <juju-core:New> <https://launchpad.net/bugs/1457728>
[04:34]  * menn0 is keen to be done with this
[04:34] <axw> menn0: done
[04:34] <menn0> axw: cheers
[04:37] <wallyworld> too quick for me
[04:40] <mup> Bug #1457728 was opened: `juju upgrade-juju --upload-tools` leaves local environment unusable <juju-core:New> <https://launchpad.net/bugs/1457728>
[04:44] <wallyworld> axw: a small one for friday arvo if you have a sec http://reviews.vapour.ws/r/1766
[04:44] <axw> wallyworld: ok
[04:45] <axw> wallyworld: I've just sent a PR for EC2 tagging, but won't tick the card over yet because I need to do OpenStack too
[04:45] <wallyworld> ok
[04:45] <wallyworld> maybe we needed 2 cards
[04:52] <axw> wallyworld: I don't think this change is safe. It would lead to machines being destroyed while there are units on it. Pretty sure the units are supposed to run stop hooks etc. before the machine is destroyed
[04:53] <wallyworld> axw: how does it do that? if there is a pending cleanup operation, the machine likfecycle is not advanced, otherwise it's just the same as now
[04:54] <wallyworld> the only change is that if there is one unit on the machine which is part of a dying service, the machine destroy doesn't error and also doesn't do anything
[04:54] <axw> wallyworld: "juju deploy mysql --to 1", <wait for unit to come up>, "juju desroy-unit mysql/0" immediately followed by "juju destroy-machine 1"
[04:55] <wallyworld> that will behave as normal
[04:55] <wallyworld> it's only if the service is dying that the new behaviour kicks in
[04:56] <axw> wallyworld: ok, so swap "destory-unit" with "destroy-service mysql"
[04:56] <wallyworld> and the new behaviour is not to error, and also not to advance machine lifecycle
[04:56]  * axw looks again
[04:56] <wallyworld> maybe a hangout to explain
[04:56] <axw> wallyworld: sorry, I thought it was still running ops
[04:57] <wallyworld> ah np
[04:58] <axw> wallyworld: I think this does break the contract of Destroy though. there's no guarantee that another service won't be added right?
[04:59] <axw> if Destroy returns, then the lifecycle should be Dying
[04:59] <wallyworld> axw: true, but then the cleanup won't run i don't think
[04:59] <axw> wallyworld: precisely
[04:59] <axw> so Destroy did not in fact do what it was supposed to
[04:59] <wallyworld> but the user doesn't get an error is what you're sayinh
[05:00] <wallyworld> so we are stuck either way
[05:00] <wallyworld> i guess it could be a warning to the user instead
[05:00] <wallyworld> ErrDestroyPendingButMightNotHappenIfSomeoneAssignsANewUnitInTime
[05:02] <wallyworld> axw: school pickup time, bbiab, maybe introduce a new error as per above
[05:03] <axw> wallyworld: maybe... I think it would be better if we allowed the machine to become Dying when it has units, but prevent it from becoming Dead until it has none. then worker/machiner would have to wait until there are no units before callign EnsureDead
[05:05] <wallyworld> axw: ok, so not a no-op, thus preventing new units, but modify the cleanup worker
[05:05] <wallyworld> that sounds like a good idea
[05:06] <axw> wallyworld: you'd have to modify worker/machiner (at least)
[05:06] <wallyworld> yep
[05:06] <axw> wallyworld: it just waits until life = Dying, then calls EnsureDead
[05:06] <wallyworld> will do that, a nicer solution, thanks
[05:06] <wallyworld> gotta run, biab
[05:06] <axw> ttyl
[05:14] <natefinch> so I accidentally renamed a file outside of bzr, and now it thinks I have removed and readded it with a different name. Is there an easy way to turn that into a bzr rename?
[05:15] <natefinch> oh, I guess just doing bzr mv worked... nevermind
[05:26] <natefinch> man bzr has terrible error messages
[05:27] <natefinch> I have a checkout of  lp:juju-ci-tools/repository  with some changes I've made.. I want to push those up to a branch under my own namespace.... I can't figure out the right incantation to make that happen
[05:27] <natefinch> thumper: ^ ?
[05:27] <natefinch> or wallyworld ^
[05:28] <thumper> natefinch: checkout or branch?
[05:28] <natefinch> thumper: I don't know how to tell
[05:28] <thumper> natefinch: plz do this and pastebin "bzr info -v"
[05:28] <natefinch> thumper: http://pastebin.ubuntu.com/11278010/
[05:29] <thumper> natefinch: yeah, checkout is so the wrong thing to do
[05:29] <natefinch> looks like checkout, but I don't know how to branch, because branch seems to expect I'm branching from somewhere else... and I just want to branch from what's right here
[05:29] <thumper> natefinch: you have something that will be remotely trying to commit to the branch on launchpad
[05:30] <natefinch> bzr branch . my-new-branch
[05:30] <natefinch> except that of course does not work
[05:30] <aisrael> bzr push lp:~username/juju-cli-tools/repository ?
[05:31] <natefinch> then I get  bzr: ERROR: Permission denied: "~natefinch/juju-cli-tools/repository/": : Project 'juju-cli-tools' does not exist.
[05:31]  * thumper tries to recall the incantation
[05:32]  * natefinch tried switch, too, to no avail
[05:32] <natefinch> $ bzr switch fill-logs
[05:32] <natefinch> bzr: ERROR: Permission denied: "Cannot create 'fill-logs'. Only Bazaar branches are allowed."
[05:32] <thumper> natefinch: bzr reconfigure --tree .
[05:33] <thumper> natefinch: that should unbind your checkout from the remote branch
[05:33] <thumper> natefinch: then
[05:33] <thumper> bzr push lp:~natefinch/juju-ci-tools/foo-bar
[05:34] <natefinch> it really does not like juju-ci-tools - bzr: ERROR: Permission denied: "~natefinch/juju-cli-tools/fill-logs/": : Project 'juju-cli-tools' does not exist.
[05:35] <natefinch> bzr: ERROR: Permission denied: "~natefinch/juju-cli-tools/repository/": : Project 'juju-cli-tools' does not exist.
[05:35] <natefinch> I'm dumb
[05:35] <natefinch> the project is juju-ci-tools
[05:38] <natefinch> except.... I think I fucked it up..
[05:38]  * natefinch should not bzr at 1:30am
[05:40] <natefinch> haha ... yeah, man.. just hadn't commited.  ok, definitely time for bed.
[05:40] <natefinch> thumper: thanks for the help
[05:41] <thumper> :)
[05:41] <thumper> np
[08:25] <fwereade> TheMue, dooferlad, voidspace: dimitern's had a power cut
[08:25] <TheMue> fwereade: ouch, thanks for the info
[08:32] <voidspace> fwereade: ok, thanks
[08:35] <dooferlad> TheMue: before the meeting (and dimitern gets his power back), what can I do to help with the planning board? Is there anything to add or review?
[08:35] <TheMue> dooferlad: not yet, the old open cards are already all moved by dimitern
[08:36] <dooferlad> TheMue: ok, thanks.
[08:36] <TheMue> dooferlad: you can take a look at the parking lot
[08:37] <TheMue> dooferlad: currently there are no cards assigned to you
[08:38] <dooferlad> TheMue: Isn't that how it is supposed to be if we are being "agile"?
[08:38] <dooferlad> TheMue: only take a card when you are ready to do something new?
[08:40] <TheMue> dooferlad: that's moving it from iteration backlog into actively working
[08:41] <TheMue> dooferlad: in my case in the backlog all those cards belong to a family of tasks. so it makes sense to assign them to one person. but that does not mean to do them all at the same time.
[08:41] <TheMue> dooferlad: first backlog, then planning of an iteration, then getting active
[08:59] <fwereade> TheMue, dooferlad, voidspace: thought/suggestion: preassigning is an antipattern. short-term impact of picking up work you're not immediately familiar with: slows down you and likely the person who write the code. long-term impact: everyone knows everything better, less silos, less bugs, more general goodness
[09:02] <TheMue> fwereade: yeah, the intention here isn't to create silos. only grouping short-term related work. but it's worth discussing even that.
[09:03] <TheMue> dooferlad: voidspace: dimitern suggests we already start the meeting, he will join later
[09:04] <dooferlad> TheMue: OK, there in a second.
[09:05] <voidspace> ok
[09:05] <voidspace> fwereade: I think I missed the context for those  comments
[09:05] <voidspace> fwereade: I agree on both points though
[09:31] <mup> Bug #1457797 was opened: Juju bootstrap fail everytime <bootstrap> <juju> <juju-core:New> <https://launchpad.net/bugs/1457797>
[10:26] <perrito666> good morning all
[10:27] <TheMue> perrito666: o/
[11:04] <voidspace> I'm getting really good at installing trusty into kvm images
[11:04] <voidspace> I've done it about eight times in the last 48 hours
[11:04] <voidspace> and I still don't have a working maas
[11:04] <voidspace> although I got closer than ever before this time
[11:04] <voidspace> I had a working maas with boot images imported and a commissioned node
[11:04] <voidspace> but the upgrade to maas 1.8 failed
[11:05] <voidspace> this time I'll try again and go directly to 1.8 instead of via the "install and upgrade" approach
[11:07] <voidspace> jw4: you will like this
[11:07] <voidspace> jw4: https://www.youtube.com/watch?v=1Zfv1LZlU9U
[11:08] <voidspace> jw4: video made by a close friend of mine, singer is our babysitter...
[11:08] <voidspace> jw4: last night it won Best Christian Music Video at the UK Christian Film Festival Awards.
[11:09] <dimitern> http://reviews.vapour.ws/r/1769/ << reviews welcome
[11:13] <TheMue> dimitern: *click*
[11:14] <TheMue> dimitern: any differences to the already done fix?
[11:16] <dimitern> TheMue, none
[11:16] <TheMue> dimitern: then it's simple ;)
[11:16] <dimitern> TheMue, indeed :)
[11:17] <TheMue> dimitern: so, done
[11:17] <dimitern> TheMue, thanks!
[12:11] <benji> voidspace: good stuff; I like the spare arrangement
[12:18] <rogpeppe1> dimitern, fwereade, jam: i'm wondering about adding a function to the juju/api which tries to dial [][]network.HostPort (the same thing returned by api.State.APIHostPorts). does that sound reasonable to you?
[12:18] <rogpeppe1> s:juju/api:juju/api package:
[12:18] <dimitern> rogpeppe1, instead of using Open?
[12:18] <rogpeppe1> dimitern: it would probably layer on top of Open
[12:19] <fwereade> rogpeppe1, that does ~the same thing as we do here and there re connecting to all of them in parallel and returning the first one that works?
[12:19] <rogpeppe1> dimitern: atm every external client needs to implement parallel dialing
[12:19] <rogpeppe1> fwereade: yes
[12:20] <fwereade> rogpeppe1, so long as you replace the existing parallel dialers with your new one, +10 :)
[12:20]  * rogpeppe1 thinks again :)
[12:21] <rogpeppe> fwereade: there's more than one?
[12:21] <fwereade> rogpeppe, I'm assuming at least the clients and the agents?
[12:21] <rogpeppe> fwereade: i was kinda hoping they used the same code. it's been a while
[12:21]  * rogpeppe looks
[12:22] <voidspace> benji: spare?
[12:23] <dimitern> rogpeppe, sgtm
[12:23] <voidspace> benji: do you mean sparse?
[12:23] <benji> voidspace: just piano and vocals
[12:23] <benji> yep
[12:23]  * dimitern is afk for a while
[12:23] <voidspace> cool, yeah it's nice
[12:24] <benji> the massive verb put me off at first, but it works once the song gets going
[12:24] <benji> I listened to it twice, so it must have been enjoyable :)
[12:41]  * TheMue is afk for a while, fetching his new car
[12:41] <perrito666> nice
[12:41] <rogpeppe> fwereade: AFAICS there's only one implementation because in agent, configInternal.SetAPIHostPorts selects only the internal addresses, so it can use the existing dial logic in api
[12:42] <fwereade> rogpeppe, doesn't it still have a bunch of addresses to choose from?
[12:42] <rogpeppe> fwereade: yes, but that logic is dealt with in api.Open
[12:43] <rogpeppe> fwereade: it's possible that i should just jam all the addresses into one slice
[12:43] <rogpeppe> fwereade: excluding any local addresss, i guess
[12:44] <fwereade> rogpeppe, ok, I'm a bit lost -- api.Open handles *some* multiple-address stuff but... doesn't parallelise?
[12:45] <rogpeppe> fwereade: there are two possible levels of parallelisation
[12:45] <rogpeppe> fwereade: because we've got [][]HostPort, not []HostPort
[12:45] <rogpeppe> fwereade: api.Open handles []HostPort but not [][]HostPort
[12:45] <fwereade> rogpeppe, ohhhhh
[12:46] <fwereade> rogpeppe, the "jam all addresses into one slice" feels reasonable offhand?
[12:46] <rogpeppe> fwereade: it kinda makes sense to do all servers in parellel, but within each server, do each address in turn
[12:46] <rogpeppe> fwereade: i dunno. there can be a lot of them
[12:46] <fwereade> rogpeppe, does it? isn't the reason for dialing multiple addresses for the same server that we don't know which might be reachable?
[12:47] <fwereade> rogpeppe, if you can somehow sort each of the inner slices by bestness, then I can see the point
[12:47] <rogpeppe> fwereade: once we know that an address *is* reachable, we should probably use that by preference for a given server
[12:47] <rogpeppe> fwereade: yes
[12:48] <fwereade> rogpeppe, I *think* there's some code that does that already
[12:48] <fwereade> ...somewhere :/
[12:48] <rogpeppe> fwereade: yeah, i seem to remember that too
[12:48] <rogpeppe> fwereade: i think it might be in api.Open
[12:51] <rogpeppe> jam: do you remember where that logic is, by any chance?
[12:51] <rogpeppe> oh bother, it's friday
[12:52] <rogpeppe> ha! found it. api.slideAddressToFront
[12:52] <rogpeppe> fwereade: ^
[12:56] <jw4> voidspace: I saw the comment on twitter a couple days ago... very nice
[13:21] <rogpeppe> fwereade: i discovered this, so i think i'll go with a similar approach for the time being. there's a lot of logic there and combined with api.Open; a more cohesive approach would probably be good at some point. http://godoc.org/github.com/juju/juju/juju#PrepareEndpointsForCaching
[13:22] <wwitzel3> ericsnow: ping
[13:22] <ericsnow> wwitzel3: present
[13:23] <wwitzel3> ericsnow: going to continue to go through what you did and make some stories on the board from it
[13:23] <perrito666> ericsnow: hb
[13:23] <ericsnow> wwitzel3: want to talk through them with me?
[13:24] <mgz> ericsnow: lots of presents? :)
[13:24] <wwitzel3> ericsnow: up to you :) I'm happy to, but don't feel obligated
[13:24] <ericsnow> perrito666, mgz: yeah, waking up early to realize my alarm clock is broken so I had better just get up :)
[13:25] <perrito666> ericsnow: hope you got a new alarm clock
[13:25] <mgz> that seems like an unexciting gift
[13:25] <ericsnow> perrito666: just shopping for one :)
[13:25] <perrito666> who uses alarm clocks these days, mine has been disconnected for years, I just have it on the night table because it is nice
[13:26] <perrito666> I had it because it was one of those ipod docks, but then apple graciously changed the connector and it no is just a nice white cube
[13:36] <ericsnow> wwitzel3: on moonstone
[13:38] <anastasiamac> ericsnow: ━═★[̲̅̅H̲̅][̲̅̅A̲̅][̲̅̅P̲̅][̲̅̅P̲̅][̲̅̅Y̲̅] [̲̅̅B̲̅][̲̅̅I̲̅][̲̅̅R̲̅][̲̅̅T̲̅][̲̅̅H̲̅][̲̅̅D̲̅][̲̅̅A̲̅][̲̅̅Y̲̅]★═━ ¸.✿¨¯`✿´¸¸.✿¨¯`✿
[13:41] <Spads> 🎂
[13:42] <alexisb> happy b-day ericsnow!
[13:50] <mup> Bug #1457895 was opened: azure-mode should not forbid targeted deployments <juju-core:New> <https://launchpad.net/bugs/1457895>
[14:02] <mup> Bug #1457895 changed: azure-mode should not forbid targeted deployments <juju-core:New> <https://launchpad.net/bugs/1457895>
[14:14] <mup> Bug #1457895 was opened: azure-mode should not forbid targeted deployments <juju-core:New> <https://launchpad.net/bugs/1457895>
[14:20] <mup> Bug #1457797 changed: Juju bootstrap doesn't work behind proxy <bootstrap> <juju> <juju-core:Invalid> <https://launchpad.net/bugs/1457797>
[14:31] <natefinch_> jw4: I wish action fetch and status would tell me the action name that go with the results.
[14:36] <natefinch_> katco: can you resend me that link?  I was logged into the wrong account
[14:36] <katco> natefinch_: yeah
[14:50] <mup> Bug #1424961 changed: provisioning stops working with local provider <deploy> <local-provider> <juju-core:Invalid> <https://launchpad.net/bugs/1424961>
[15:03] <natefinch> wwitzel3: embiggen plz
[15:23] <jw4> natefinch: really good point!
[15:23] <jw4> natefinch: I'm gonna use Actions 2.0 to trojan in a bunch of enhancements hopefully
[15:25] <jw4> natefinch: I'm not sure exactly how we're going to fix a bunch of the usability issues with actions 1.0 - I wish we'd clearly labeled the api and cli as beta
[15:28] <natefinch> jw4: seems like adding a new key to the output wouldn't hurt anything.. parsers should ignore extra data they don't understand anyway
[15:29] <natefinch> course... you never know when someone might have a poorly thought out script
[15:31] <jw4> natefinch: true - your request shouldn't change much... there's just a bunch of fiddly little things
[15:59] <mup> Bug #1457797 was opened: Juju bootstrap doesn't work behind proxy <bootstrap> <juju> <juju-core:Incomplete> <https://launchpad.net/bugs/1457797>
[16:25] <alexisb> natefinch, katco, ericsnow, wwitzel3: loving the demo videos!
[16:25] <natefinch> alexisb: :)
[16:25] <ericsnow> alexisb: :)
[16:26] <wwitzel3> alexisb: thanks
[16:34] <katco> alexisb: :)
[16:41] <natefinch> ericsnow: btw, this is what I mean by function-scoped variables in python:  https://repl.it/pIP
[16:44] <natefinch> ericsnow: as opposed to block scoped, like Go: http://play.golang.org/p/ADdQIO9GaP
[16:44] <ericsnow> natefinch: oh, you mean that basically only blocks (functions, classes, and modules) in Python define scopes?  and that indentation does not (necessarily)
[16:44] <natefinch> ericsnow: yes
[16:44] <ericsnow> natefinch: I could see how that would be confusing at first
[16:45] <natefinch> ericsnow: when you're used to block scope (where any branch counts as a block), function-scope is really confusing.
[16:46] <mgz> ehe, but go lets you do all kinds of ugly shadowing that messes up with their scoping rules...
[16:46] <ericsnow> natefinch: yeah, just think of it as Python only has scope against function bodies (and modules/class definitions are just special case functions)
[16:47] <mgz> the practice of using 'err' as the name everywhere can create some fun bugs
[16:49] <natefinch> mgz: pretty much any language let you shadow variables from a higher scope, the reason it's different for go is the confusion between = and :=
[16:50] <natefinch> mgz: for example, you can shadow trivially in python: https://repl.it/pIW
[16:51] <natefinch> python just doesn't have block scope
[16:51] <natefinch> mgz: sorry, better example: https://repl.it/pIW/1
[16:51] <mgz> natefinch: sure, in practice you get less of it with fewer scopes existing
[16:52] <mgz> people do still confuse themselves
[16:52] <natefinch> and in languages where you can't shadow, you get crap like err1 err2 err3, etc
[16:53] <mgz> err, inner_err, inner_inner_err...
[16:54] <natefinch> if Go didn't have := and you had to declare every variable as var foo = "bar"  .... it would be much more obvious where the shadowing was occurring. But it would also be annoyingly more verbose.  It's a tradeoff.
[17:20] <voidspace> right, happy weekend everyone
[17:20] <voidspace> see you on Tuesday!
[17:20] <natefinch> voidspace: see ya
[17:40] <katco> natefinch: heyo, back yet?
[17:44] <natefinch> mgz, sinzui, abentley: https://github.com/juju/juju/wiki/Testing
[17:46] <sinzui> natefinch, cd juju-ci-tools; make install-deps
[17:46] <sinzui> that will provide the real deps need by the files