[00:10] <davecheney> thumper: menn0 waigani i've been working on some visualisation tools to help me
[00:10] <davecheney> https://twitter.com/davecheney/status/534135954420678656
[00:10] <davecheney> here is an example
[00:10] <davecheney> dealing with something the size of juju/state is still daunting
[00:10] <waigani> nice!
[00:10] <davecheney> that is cmd/juju
[00:10] <davecheney> sorery
[00:10] <davecheney> cmd/go
[00:11]  * menn0 is still waiting for twitter to load the image
[00:12] <waigani> davecheney: is that d3?
[00:12] <menn0> wow that's awesome
[00:12] <menn0> what are you using to do the rendering?
[00:13] <davecheney> waigani: d3js.org
[00:13] <waigani> thought so
[00:26] <davecheney> http://imgur.com/t57nMob
[00:26] <davecheney> ^ juju/state
[00:26] <waigani> menn0: can I talk over the allwatcher store with you? I can see two ways to go
[00:26] <davecheney> http://imgur.com/3oErTdQ
[00:26] <davecheney> juju state, from the perspective of mgo/v2
[00:26] <waigani> davecheney: omg...
[00:28] <menn0> waigani: i was about to go for lunch...
[00:28] <menn0> waigani: did you want to hangout/
[00:28] <waigani> menn0: should be a quick question
[00:28] <waigani> menn0: standup hangout?
[00:28] <menn0> waigani: ok
[00:30] <davecheney> http://i.imgur.com/ioxieyg.png
[00:30] <davecheney> something to consider with the juju/version pacakge
[00:33] <davecheney> http://imgur.com/d9xNtae
[00:33] <davecheney> who's using loggo, and who isnt ...
[00:35] <thumper> davecheney: so the picture is showing what?
[00:35] <thumper> what are the lines?
[00:35] <thumper> and how do you know?
[00:35] <thumper> is there meaning to the relative thickness?
[00:36] <davecheney> thumper: it's a bit hard to tell
[00:36] <thumper> davecheney: it is almost like you need two graphs rather than one
[00:36] <davecheney> i stole most of the code from an example comparing people who like different hair color
[00:36] <davecheney> i'll keep working on it tonight
[00:37] <thumper> kinda cool picture though
[00:37] <davecheney> at leats it tells me who is relaed to what
[00:37]  * thumper nods
[00:37] <davecheney> like juju/version imports bson ...
[00:38] <davecheney> http://imgur.com/UKYv5j3
[00:38] <davecheney> this is all the things that importing juju/version brings in
[00:39] <davecheney> which seems excessive
[00:39] <davecheney> like why does juju/version depend on sync ...
[00:40] <davecheney> http://imgur.com/nmfRE4r
[00:45] <anastasiamac> davecheney: these look pretty!
[00:45] <anastasiamac> davecheney: are they available on the fly?
[00:45] <anastasiamac> davecheney: kinf of like "graph usage of blah"?
[00:46] <anastasiamac> s/kinf/kind
[00:48] <davecheney> anastasiamac: go get github.com/davecheney/junk/glyph
[00:48] <davecheney> $GOPATH/bin/glyph
[00:48] <davecheney> then go to localhost:8080/chord/cmd/go
[00:48] <davecheney> it works just like godoc, the first url is the visualisation, the rest is a package path to start from
[00:48] <davecheney> be warned
[00:48] <davecheney> it is very very slow
[00:48] <davecheney> took two minutes to generate the first image
[00:49] <anastasiamac> davecheney: it's monday... i feel slow too :-)
[00:49] <davecheney> i'm doing to much processing in the browser
[00:49] <davecheney> i need to offload that to the backend
[00:51] <anastasiamac> davecheney: thnx :-) visually seeing dependencies is enormously helpful!
[00:51] <davecheney> that's why i built this
[00:51] <davecheney> i need it to help me
[00:52] <thumper> davecheney: juju/version brings in io (to read the file), io brings in sync
[00:52] <thumper> davecheney: easy to pull in heaps
[00:52] <davecheney> versino is also bringing in sync directly
[00:52] <davecheney> which is odd
[00:53] <davecheney> hmm
[00:53] <davecheney> no it isnt
[00:53] <davecheney> ok
[00:53] <davecheney> i screwed up
[00:53] <davecheney> doesn't surprise me
[01:03] <thumper> davecheney: just checking that we both aren't sitting in a different hangout with the same name
[01:03] <thumper> google gets things wrong occasionally
[01:04] <davecheney> thumper: nope, my bad
[01:04] <davecheney> i ingored the reminder
[01:04] <davecheney> be there in a sec
[01:21] <davecheney> thumper: http://godoc.org/github.com/juju/juju/state?import-graph
[01:23] <davecheney> thumper: http://imgur.com/TT3xgeD
[01:25] <davecheney> thumper: http://imgur.com/2iKJC2O
[01:58] <thumper> davecheney: https://github.com/juju/errors/pull/13
[01:58]  * thumper takes broken kid to physio
[02:41] <menn0> waigani: http://reviews.vapour.ws/r/471/ reviewed
[03:30] <axw> wallyworld_: when you have a minute, can you PTAL at http://reviews.vapour.ws/r/442/
[03:30] <wallyworld_> sure
[03:31] <axw> wallyworld_: I've parameterised the function to list block devices in worker/diskmanager.NewWorker
[03:31] <axw> with a default
[03:31] <axw> jujud tests now override that default
[03:38] <wallyworld_> axw: looks good, now tests will pass in a container
[03:40] <axw> yep
[03:40] <axw> thanks
[03:49] <waigani> menn0: thanks for the review. testing the constraints upgrade, I've expected three records because there is a preexisting environment constraints doc
[03:49] <waigani> menn0: i.e. it has a local i.d. of "e" - the global env key
[03:51] <thumper> wallyworld_: hey, can I get you to look at this for me? https://github.com/juju/loggo/pull/7/files
[03:51] <wallyworld_> sure
[04:00] <wallyworld_> thumper: the location stuff is just for tests to avoid hard coding line numbers?
[04:00] <thumper> wallyworld_: exactly
[04:00] <thumper> stolen from the errors tests, which I got from rog
[04:00] <wallyworld_> can you add a doc comment then so the next person doesn't need to fiure it out?
[04:00] <thumper> sure
[04:00] <wallyworld_> also, i think then the test commnt is wrong
[04:00] <wallyworld_> as it still mentions line number fragility
[04:01] <thumper> ah... will fix
[04:04] <thumper> wallyworld_: changes pushed
[04:04] <wallyworld_> +1
[04:05] <thumper> cheers
[04:10] <menn0> waigani: of course... I didn't think of that
[04:13] <waigani> menn0: cool, so good to ship?
[04:13] <menn0> I think so
[04:14] <menn0> just wondering if the test should check that the "e" key is still in good shape post migration
[04:14] <menn0> waigani: ^
[04:14] <waigani> menn0: shesh, just caught me - mouse was over the 'commit' button
[04:15] <thumper> wallyworld_: and a useful one: https://github.com/juju/loggo/pull/6/files
[04:16] <menn0> waigani: it's probably ok
[04:16] <waigani> menn0: I do check that in TestAddEnvUUIDToConstraintsIdempotent
[04:16] <waigani> menn0: so it is covered. good enough?
[04:17] <menn0> waigani: so you do. that's great then. can you just add a comment with the assertion that check for a length of 3 to avoid confusion
[04:17] <menn0> waigani: then merge away
[04:17] <waigani> menn0: will do
[04:18] <menn0> thumper: so State.NewEnvironment doesn't give you an environment you can do anything with
[04:18] <thumper> no
[04:18] <thumper> menn0: it just adds an environment into the collection
[04:18] <thumper> menn0: happy if you want to change that
[04:18] <thumper> menn0: it probably isn't used in many places
[04:18] <wallyworld_> thumper: so how to developers decide to use the Stack vs non Stack variants of the various log methods
[04:19] <wallyworld_> shouldn't they just use Warningf() and a log setting decides
[04:19] <thumper> wallyworld_: if you are logging a message, you go `logger.Infof("some garbage")`
[04:19] <menn0> thumper: it isn't used anywhere, except tests
[04:19] <thumper> wallyworld_: the InfoStackf takes an error as the first param
[04:20] <thumper> wallyworld_: magical introspection of the args... params would be a bit too magic
[04:20] <menn0> thumper: so basically we need Initialize (in open.go) to happen afterwards right?
[04:20] <thumper> wallyworld_: if you want the error stack logged, call the stack message
[04:20] <thumper> menn0: if you want to use it, yes
[04:20] <wallyworld_> ok
[04:20] <wallyworld_> i'm not sure then we need all the variants
[04:21] <thumper> wallyworld_: there are many many occurrances of logging where we go `logger.Warningf("something horrible: %v", err)`
[04:21] <wallyworld_> would we really want to see a stack trace for an Info message
[04:21] <thumper> I'm thinking that it would be `logger.WarningStackf(err, "something horrible")`
[04:21] <thumper> wallyworld_: I don't want to make that call
[04:21] <thumper> wallyworld_: someone may want a stack at a different level
[04:22] <wallyworld_> if they need stack trace with an info there's something wrong
[04:22] <wallyworld_> but ok
[04:22] <wallyworld_> i think this will be absed
[04:23] <thumper> abused?
[04:23] <wallyworld_> yeah
[04:23] <thumper> I'm not sure.. I guess time will tell
[04:23] <menn0> thumper: Initialize doesn't quite work as it dials it's own mongo connection and create its own uuid etc
[04:23] <wallyworld_> our log output will become oven more of a firehose
[04:23] <thumper> I have a better one coming
[04:23] <menn0> thumper: I will do some refactoring
[04:23] <thumper> menn0: ack
[04:24] <wallyworld_> thumper: what do we do when our log files are full of stack traces and even harder to read than they are now
[04:25] <thumper> wallyworld_: I think this becomes one of those pragmatic things, don't record a stack for an expected error
[04:26] <wallyworld_> i think we need x-team collaboration or a policy that reviewers are aware of so that this will not be misused
[04:27] <wallyworld_> clear guidelines on what an "expected" error is
[04:27] <wallyworld_> what's the driver for this?
[04:27] <wallyworld_> is there an issue that is being solved?
[04:30] <thumper> one of the issues was our logging, and that I was looking for occurrances of ": %v" in the codebase
[04:30] <thumper> I saw that many were to log errors
[04:30] <thumper> we now catch error stack info which is important for debugging
[04:30] <thumper> that was the rationale
[04:31] <thumper> wallyworld_: along with this one: https://github.com/juju/testing/pull/38/files
[04:31] <wallyworld_> i content you don't need the error stack 99% of the time
[04:32] <wallyworld_> and if you do, it is for debugging, and not warning or error or info output
[04:32] <wallyworld_> i have very rarely if ever wished to have the stack trace when debugging a juju issue
[04:32] <thumper> hmm...
[04:33] <wallyworld_> sorry for being -1 on this, i just see a whole lot of extra logging for little benefit
[04:33] <wallyworld_> but that's just IMHO
[04:34] <thumper> I'm happy to hold off landing that one until we talk as a team through it more
[04:34] <thumper> I can take it to the list
[04:34] <wallyworld_> i'd personally be happier if this were a trace level thing that could be turned on when needed
[04:34] <thumper> but probably tomorrow
[04:34] <thumper> wallyworld_: or just a separate method:
[04:34] <thumper> logger.StackTrace(err)
[04:34] <thumper> although...
[04:34] <wallyworld_> so long as it can be turned on/off
[04:34] <thumper> I had thought of having other helper methods:
[04:35] <thumper> one to get a limited stack trace of where you are
[04:35] <thumper> the other to get the stack trace of the error you have
[04:35] <wallyworld_> this could be useful when developing (not foe me, but others might like it)
[04:36] <wallyworld_> but it should not get into our std log output by default
[04:36] <wallyworld_> happy to concede if the majority want it
[04:36] <thumper> I'll take this one to the list
[04:36] <wallyworld_> ta
[04:36] <thumper> the other is `jc.IsNil`
[04:36] <wallyworld_> ok
[04:37] <thumper> which does " if not nil, and it is an error, and it has a StackTrace method, show the stack trace in the test fail message"
[04:37] <wallyworld_> now, that is useful
[04:37] <thumper> which I have wanted for a while
[04:38]  * thumper goes to make dinner for the little beings that live at his house
[04:50] <wwitzel3> axw: can you take a look at https://github.com/juju/juju/pull/1157
[04:50] <axw> looking
[04:54] <axw> wwitzel3: I can't spot the problem that was fixed - can you please describe?
[04:54] <wwitzel3> axw: well this was actually done before you merge landed adding in the break.
[04:56] <waigani> wtf?
[04:56] <axw> wwitzel3: so is this really necessary then? there are tests for zone selection already, TestStartInstanceDistribution.*
[04:57] <waigani> I just merged trunk and pushed my diff up to RB. What should be a four line diff has turned into a 400 line diff.
[04:57] <axw> also, the "continue" in the refactored function should still do an index check, otherwise the message is wrong on the last iteration
[04:57] <waigani> http://reviews.vapour.ws/r/473/diff/
[04:57] <wwitzel3> axw: well I think the refactor is better, since it extracts the concern out of a big monolithic method and helps to isolate the testing :)
[04:58] <waigani> other than the megawatcher changes, none of those changes are mine.
[04:58] <axw> wwitzel3: yes, that is a fair point
[04:58] <waigani> from this branch at least
[04:58] <wwitzel3> axw: yeah, I think that got clipped out in a merge, I just noticed that
[04:59] <wwitzel3> axw: I wanted you to give me a review on it since you did the code, but I'd stil like to land it
[04:59] <axw> wwitzel3: sure. LGTM with the continue condition readded
[05:01] <davecheney> http://imgur.com/94R6MwG
[05:01] <davecheney> the agent package is a bit of a beast
[05:01] <wwitzel3> axw: on the condition, is can I use <= instead of i+1 < ?
[05:01] <axw> wwitzel3: that's fine with me
[05:02] <wwitzel3> axw: k, yeah, that is what I changed, but I think I foobar'd a merge and ended up squashing the entire if block :/
[05:02] <axw> davecheney: looks like a DHT; it's got some extra deps in case someone removes one ;)
[05:04] <wwitzel3> axw: thanks, addressed both of those
[05:05] <axw> wwitzel3: thanks for making it better :)
[05:05] <axw> wwitzel3: did you figure out that latest MAAS provider bug btw? last I looked you couldn't repro
[05:10] <waigani> menn0: something between git, github and RB crapped itself along the way, so new PR: http://reviews.vapour.ws/r/474/
[05:21] <wwitzel3> axw: yeah, the bug was their code didn't have the back port of the "break" yet.
[05:21] <wwitzel3> axw: so instead of stopping after finding the right zone, it just kept running until the last zone.
[05:21] <wwitzel3> axw: and it just happened their last zone was full
[05:22] <wwitzel3> axw: I couldn't repo at first because my last zone had a free slot.
[05:23] <axw> wwitzel3: ahh I see, thanks
[05:28] <wwitzel3> axw: now I just have to figure out why my test fails on the bot , but works locally :( .. sad day, guess I will save that for tomorrow
[05:31] <axw> wwitzel3: nothing jumps out
[06:09] <anastasiamac> axw: could u plz clarify juju convention when creating pair of corresponding commands?
[06:09] <anastasiamac> axw: do they sit in one file like in environment.go - set/unset
[06:10] <anastasiamac> axw: do they sit in different files like addmachine.go and removemachine.go?
[06:10] <axw> anastasiamac: I think most people prefer one command per file
[06:10] <anastasiamac> axw: sorry ;-(
[06:10] <anastasiamac>  set/get for environment
[06:11] <anastasiamac> axw: k.. one file  is gr8 ;-)
[06:11] <anastasiamac> axw: thnx
[06:11] <axw> anastasiamac: nps
[06:11] <anastasiamac> axw: so where would u put shared functionality?
[06:12] <anastasiamac> axw: i'd like to avoid duplicate code
[06:12] <axw> anastasiamac: I'd just stick all common functionality in one or the other, doesn't matter which... just as long as it's together
[06:13] <anastasiamac> axw: k. sure :-) thnx
[07:10] <wallyworld_> jam: you ok for the juju status meeting later?
[07:28] <jam> wallyworld_: I should be able to be around
[07:29] <wallyworld_> great, we need to get the spec approved, and there's a fair bit of disagreement
[07:31] <axw> dimitern: why does goamz use a different API version for RunInstances when specifying VPC attributes? were you being paranoid, or is there actually different behaviour?
[07:32] <dimitern> axw, because the VPC API is a newer version than the classic api it otherwise uses
[07:32] <dimitern> axw, and yes, I was being a bit paranoid :)
[07:32] <axw> dimitern: I realise.. I meant, why not use the newer version on all
[07:32] <axw> ok
[07:33] <axw> dimitern: I'm just asking because I'm going to have to bump the version we use to support allocating additional EBS volumes
[07:34] <dimitern> axw, sure, if you need to, but please sync up with niemeyer
[07:34] <axw> dimitern: will do
[07:48] <jam> wallyworld_: any news about the remaining critical bugs ? Do you need some extra manpower to work on them ?
[07:49] <jam> like https://bugs.launchpad.net/juju-core/+bug/1392544 isn't assigned yet
[07:49] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[07:49] <wallyworld_> jam: i poked tim about bug 1392745 as i suspect he'll be across it, but he deferred till tomorrow
[07:49] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[07:50] <wallyworld_> the local provider one i'm going to start looking at
[07:50] <wallyworld_> the default value one is not assigned yet, if you had someone who could look that would be good
[07:50] <wallyworld_> otherwise i'll do tomorrow
[07:50] <jam> wallyworld_: k, if you want someone on my team, I'm perfectly happy having us polishing a release branch
[07:51] <wallyworld_> ok, thanks, maybe the default value one then
[07:52] <mattyw> morning all
[07:53] <jam> wallyworld_: k, I'm not sure if they'll get up to speed before someone like Tim could fix it, but I can get them started.
[07:54] <wallyworld_> jam: tim will do the 1.20.11 juju run one
[07:55] <wallyworld_> i haven't look in default at the default value one
[07:55] <wallyworld_> in detail
[07:55] <jam> ah, ok
[07:56] <wallyworld_> bug 1392544 should just be some generic snafu maybe
[07:56] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[07:56] <jam> wallyworld_: yeah. It looks like something is casting everything to a generic boolean type
[07:57] <jam> wallyworld_: I've tasked dimitern with it
[07:57] <wallyworld_> the other one - the local provider log issue - is likely tim's aread also, but i'll did into it
[07:57] <wallyworld_> ty
[07:57] <wallyworld_> and the maas one is well in hand
[08:03]  * fwereade_ was up late last night, is going for a bit of a walk before he starts properly
[08:22] <axw> fwereade_: when you have started, if you have some time would you please take a glance over https://github.com/juju/charm/pull/77? doesn't need to be a full review, but I'd like to know if you have had differing thoughts on how the storage metadata should look
[10:00] <dimitern> fwereade_, ping
[10:00] <fwereade_> dimitern, pong
[10:01] <dimitern> fwereade_, re https://bugs.launchpad.net/juju-core/+bug/1392544 - what's the purpose of the "default: true|false" field in juju get svcname output?
[10:01] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged by dimitern> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[10:02] <fwereade_> dimitern, it tells you whether it's that value because [nothing was set, and it will therefore change if there's a charm upgrade that changes the default] or [that's the actual value that was explicitly set, even if it happens to match the default, and will persist so long as there's a matching config entry]
[10:02] <jam> TheMue: voidspace: standup ?
[10:03] <dimitern> fwereade_, so if "default: true" it means yeah the respective config setting is not set (i.e. uses the default value) ?
[10:03] <fwereade_> dimitern, yeah
[10:04] <fwereade_> dimitern, looking at that bug I suspect it's a documentation issue more than anything
[10:04] <dimitern> fwereade_, it seems to me as well, but I'll do a quick test to make sure we don't set default: true for non-default values
[10:04] <fwereade_> dimitern, thanks
[10:04] <fwereade_> dimitern, don't close the bug without fixing the docs, though, please :)
[10:04] <voidspace> jam: oops
[10:04] <voidspace> jam: omw
[10:04] <dimitern> fwereade_, sure
[10:05] <fwereade_> dimitern, <3
[10:06] <jam> fwereade_: so for compat reasons, can we ever change that to "is-default" rather than "default" confusing people ?
[10:08] <fwereade_> jam, yes and no. no for `juju get`; yes for `juju service get`, which I'll need to sync up with thumper on
[10:09] <fwereade_> jam, however, for `juju service get` we really want the default output to be something we can pass back into `juju service set`
[10:09] <fwereade_> jam, so a sane implementation would probably just skip the ones with default values
[10:09] <fwereade_> jam, and a --schema flag or something could tell you what the defaults were
[10:10] <jam> fwereade_: we *could* have that as "--as-set" or some other flag that indicates the output you want. I think you *do* sometimes want to see what the value is, even if you haven't set it
[10:10] <fwereade_> jam, that is not perfect for sure
[10:10] <jam> I've used it often to figure out what I *could* set
[10:10] <fwereade_> jam, I agree we do
[10:10] <jam> fwereade_: you'd prefer the minimal form as the default output ?
[10:10] <fwereade_> jam, but the asymetry between get and set is really kinda nasty
[10:11] <fwereade_> jam, I *think* so, yeah -- in my mind the main tension is in what happens if you get, upgrade, set
[10:11] <fwereade_> jam, and whether that final set shoudl change values or not
[10:11] <fwereade_> jam, (assuming it's not rendered irrelevant by the original get having values that are invalid/unknown post-upgrade
[10:11] <fwereade_> )
[10:12] <fwereade_> jam, not saying it should be *hard* to see the possibilities, but I don't think it's the *most* important thing
[10:13] <jam> fwereade_: well, I do think it is the primary use case of get, isn't it ? (what are all the current settintgs)
[10:13] <jam> fwereade_: or do you feel it is more the way you transfer settings to some other place
[10:14] <fwereade_> jam, `get --all` feels appropriate for "and include the defaults please" -- it's more consistent with charm-side config-get apart from anything else
[10:15] <fwereade_> jam, and `get --schema` feels appropriate for "tell me what the possible keys and their meanings are"
[10:15] <fwereade_> jam, and I'm not automatically opposed to some nice human-readable combination of the two
[10:15] <fwereade_> jam, but it feels like a lot of disparate info to cleanly fit into the default output
[10:16] <fwereade_> jam, that's what we signally failed to do with the current implementation ;)
[10:26] <perrito666> morning
[10:29] <dimitern> fwereade_, so it does work - setting a service config setting to a non-default value causes juju get svcname to *not* include "default: true" for that setting
[10:30] <fwereade_> dimitern, that's good anyway
[10:30] <fwereade_> dimitern, not really much less confusing
[10:30] <fwereade_> dimitern, but at least working as intended
[10:31] <dimitern> fwereade_, so what do you suggest to add to juju help get to clarify the behavior?
[10:31]  * fwereade_ looks at documentation for `juju get`
[10:32] <fwereade_> dimitern, um, some documentation ;p
[10:32] <dimitern> fwereade_, because this is what I think the "fix" for that bug
[10:32] <fwereade_> dimitern, concur
[10:32] <dimitern> fwereade_, barely :)
[10:32] <fwereade_> dimitern, seriously, all it has is a "purpose"
[10:32] <fwereade_> dimitern, give it a Doc as well
[10:32] <dimitern> fwereade_, yeah, a lot of commands (simpler ones) are like that
[10:32] <fwereade_> dimitern, indeed
[10:33] <fwereade_> dimitern, this is not actually a good thing ;)
[10:33] <dimitern> fwereade_, ok, I'll describe the output in the Doc of get
[10:35] <fwereade_> dimitern, cool, thanks
[11:33] <dimitern> fwereade_, trivial review (mostly proof-reading I guess) ? https://reviews.vapour.ws/r/477/diff/
[11:35] <fwereade_> dimitern, ship it
[11:35] <dimitern> fwereade_, cheers!
[11:35] <fwereade_> dimitern, hey, btw, apparently malta played football against bulgaria and didn't lose, I feel quite unwarrantedly smug on behalf of my place of residence
[11:36] <dimitern> fwereade_, :) yeah, I've heard of that
[11:36] <dimitern> fwereade_, and also BG won 2nd place in the kids eurovision in malta
[11:36] <fwereade_> dimitern, cool, I didn't know that until today either :)
[11:37] <dimitern> fwereade_, btw can you actually click on Ship it! ? :)
[11:37] <dimitern> fwereade_, ah, sorry - I've just seen it, it must've been lagging behind
[11:42] <dimitern> niedbalski, ping
[11:47] <dimitern> voidspace, jam, can any of you please approve https://reviews.vapour.ws/r/478/ ? it's the same fix for bug 1392544, this time for master
[11:47] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1392544>
[11:49] <voidspace> dimitern: looking
[11:49] <dimitern> voidspace, ta
[11:51] <voidspace> dimitern: lgtm
[11:51] <dimitern> voidspace, thanks
[11:53] <dimitern> voidspace, did you click "Ship It!" btw?
[11:53] <voidspace> dimitern: yes
[11:54] <voidspace> dimitern: I really did
[11:54] <voidspace> dimitern: I've done it twice, but it doesn't seem to be showing up
[11:54] <dimitern> voidspace, yeah, weird...
[11:54] <voidspace> dimitern: I got an "untrusted connection" warning when I went to RB too
[11:54] <dimitern> voidspace, anyway, ta, I'll ping eric later about this
[11:55] <voidspace> dimitern: if I use http it works
[11:55] <voidspace> dimitern: https fails
[11:55] <voidspace> odd
[11:55] <voidspace> dimitern: Ship It! now visible anyway
[11:56] <dimitern> voidspace, ha! I've seen this as well - using https I had to add an exception because the cert was self-signed most likely
[11:56] <voidspace> dimitern: yeah, I added the exception ok
[11:56] <voidspace> dimitern: but if I use https then ship it doesn't work
[11:57] <dimitern> voidspace, really odd
[11:57] <voidspace> rogpeppe3: ping
[11:57] <voidspace> rogpeppe2: ping
[11:57] <voidspace> rogpeppe1: ping
[11:57] <rogpeppe3> voidspace: pong
[11:57] <voidspace> rogpeppe3: hello Roger
[11:57] <rogpeppe> voidspace: hiya
[11:57] <voidspace> rogpeppe: morning
[11:57] <rogpeppe> voidspace: how's it going?
[11:57] <voidspace> rogpeppe: is there a tool for applying changes  to go code that works by ast rewriting
[11:57] <voidspace> rogpeppe: like "go fix" but a general tool
[11:57] <rogpeppe> voidspace: gofmt :)
[11:58] <voidspace> rogpeppe: ah!
[11:58] <voidspace> rogpeppe: cool, thanks
[11:58] <rogpeppe> voidspace: check out gofmt -r
[11:58] <voidspace> rogpeppe: all is good, how's you?
[11:58] <rogpeppe> voidspace: but it depends what you want to do
[11:58] <voidspace> rogpeppe: do I need "gofmt" rather than "go fmt"
[11:58] <rogpeppe> voidspace: excellent, thanks
[11:58] <rogpeppe> voidspace: go fmt invokes gofmt
[11:58] <voidspace> rogpeppe: I want to rename an Interface method and all uses
[11:58] <voidspace> rogpeppe: ah, ok - I understood there were some historical differences
[11:59] <rogpeppe> voidspace: you possibly want to (brand new) gorename tool actually
[11:59] <rogpeppe> voidspace: the interface to go fmt is in terms of packages; the interface to gofmt is stdin/stdout and files
[11:59] <voidspace> rogpeppe: ok
[12:00] <rogpeppe> voidspace: i haven't succeeded in using it on a large code base yet though
[12:00] <voidspace> rogpeppe: ah :-)
[12:00] <rogpeppe> voidspace:  but take a look at https://groups.google.com/forum/#!topic/golang-nuts/96hGPXYfqsM
[12:00] <voidspace> rogpeppe: I'm there already
[12:00] <rogpeppe> voidspace: if the method name is distinctive, then gofmt -r will probably do your job ok
[12:05] <voidspace> hmmm... gorename can't find the environs package it seems
[12:05] <voidspace> I'll try go fmt
[12:05] <wallyworld> jam: meeting?
[12:05] <jam> wallyworld: omw
[12:06] <jam> wallyworld: .... firefox just froze, be there in a sec
[12:06] <wallyworld> np
[12:23] <voidspace> dimitern: when you get a chance http://reviews.vapour.ws/r/479/
[12:23] <voidspace> dimitern: it builds fine (so is probably correct), just running all tests
[12:23] <voidspace> dimitern:  I used gofmt, but ended up having to use sed to fix comments (and then manually unfix some of things sed did)
[12:24] <voidspace> dimitern: so I might as well just have started with sed...
[12:26] <dimitern> voidspace, :) ok, looking
[12:27] <voidspace> dimitern: ooh
[12:27] <voidspace> dimitern: "Subnets returns basic information about all networks known"
[12:27] <voidspace> dimitern: should probably be
[12:28] <voidspace> dimitern: Subnets returns basic information about all subnets known
[12:28] <voidspace> dimitern: I'll make that change
[12:28] <dimitern> voidspace, yeah, I've just added a comment for this
[12:29] <voidspace> dimitern: pushed
[12:29] <voidspace> dimitern: I don't think you've published that comment yet anyway
[12:30] <dimitern> voidspace, LGTM, just sent my comment
[12:30] <voidspace> dimitern: cool, thanks
[13:04] <dimitern> voidspace, a bit of a problem
[13:04] <dimitern> voidspace, did you remember to rename ListNetworks to Subnets in environs/interface.go ?
[13:05] <dimitern> voidspace, because I see lots of build errors like *joyentEnviron does not implement environs.Environ (missing ListNetworks method)
[13:05] <dimitern> voidspace, I can't even say how this managed to land, because it does not build :)
[13:24] <dimitern> voidspace, ah, sorry - something was messed up with my local git repo - now it seems to work and there are no failures
[14:11] <sinzui> wwitzel3, is bug 1392390 not fix committed in master?
[14:11] <mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Fix Committed by wwitzel3> <juju-core 1.21:In Progress by wwitzel3> <https://launchpad.net/bugs/1392390>
[14:12] <rogpeppe> fwereade_: do we check anywhere that a charm must have an install and/or a start hook?
[14:12] <fwereade_> rogpeppe, nope
[14:13] <rogpeppe> fwereade_: ok, cool
[14:13] <rogpeppe> fwereade_: i could've sworn it did, but couldn't find the code
[14:13] <wallyworld> wwitzel3: is nate around?
[14:19] <jw4> mgz, wallyworld out of disk space on CI build server?
[14:20] <wallyworld> jw4: just retry
[14:20] <jw4> kk
[14:20] <jw4> tx wallyworld
[14:20] <wallyworld> happens sometimes :-(
[14:20] <jw4> :)
[14:21] <wallyworld> perrito666: when wwitzel3 or nate are around, could you mention bug 1392602 - i cannot find wtf is happening. it could be related to recent logging work, but i'm not sure. maybe they will have an idea
[14:21] <mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
[14:37] <mgz> jw4: it's still not clear what triggers that failure... but just retrying works
[14:38] <jw4> mgz: yeah weird.  I've $$retried$$ and so far it's looking good
[14:38] <jw4> mgz: tx
[14:39] <jw4> mgz: derp... now I get "failed to find "mongod"
[14:39] <mgz> >_<
[14:39] <voidspace> fun
[14:39] <mgz> jw4: I'll investigate, also seems like an 'ec2 is ill' type of issue
[14:39] <jw4> bummer
[14:40] <jw4> thx mgz
[14:40] <jw4> mgz: shall I $$retry$$ or wait?
[14:40] <mgz> jw4: this one is just "no reachable servers" no? an intermittent test failure.
[14:40] <jw4> mgz: yeah
[14:41] <mgz> though... I agree I've not seen MongoSuite.TestAddRemoveSet fail quite like that before
[14:43] <jw4> mgz: lol it was because the build number was '1337'
[14:43] <jw4> ;)
[14:43] <mgz> http://paste.ubuntu.com/9057111/
[14:43] <mgz> jw4: send it through again
[14:44] <jw4> k
[14:49] <wwitzel3> sinzui: it is fix commited in master, I am getting the patch up for 1.21 now, not sure how it go reverted in lp, probably my fault :)
[14:49] <sinzui> wwitzel3, thank you for following up
[14:57] <perrito666> wwitzel3: natefinch ericsnow Ill be a couple of mins later, I am hogging my bw with a deploy
[14:58] <natefinch> k
[15:05] <natefinch> wwitzel3: ping?
[15:05] <wwitzel3> natefinch: yep, sorry
[15:16] <sinzui> natefinch, I think bug 1392745 needs to attention, can you find someone to look into it? I amd jjo can gather information as needed
[15:16] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[15:16] <sinzui> natefinch, and I can offer access the the juju-ci3 env if someone needs to be on an affected env
[15:17] <mgz> jw4: you're a lucky one today
[15:17] <mgz> latest run, not seen a failure on this test before...
[15:17] <mgz> FAIL: metricmanager_test.go:20: MetricManagerSuite.TestRunner
[15:17] <mgz> looks like it's timing dependent though
[15:22] <mgz> jw4: test you added, so probably needs fixing?
[15:23] <mgz> wait... is that run not yours? I am confused
[15:23] <mgz> mattyw: ^
[15:24] <mattyw> mgz, ah shit - I'll take a look, didn't realise that test had landed yet - probably only landed 10 minutes ago
[15:24] <jw4> hmm; I'll investigate... I don't think it was mine
[15:25] <mattyw> mgz, jw4 it's all good
[15:25] <mattyw> mgz, jw4 it's failed trying to land the branch that test was added in - so the tests are doing their job
[15:25] <jw4> mattyw: cool, tx!
[15:25] <jw4> I'll try mine again for the fourth time
[15:26] <mattyw> jw4, I don't think you'd have seen that error? looks like my branch hasn't landed
[15:26] <jw4> mattyw: right - my integration builds were failing due to space issues on the ci server
[15:27] <mgz> yeah, I'd just assumed the in-progress landing was jw4's again, but it was mattyw's, hence the confusion, sorry :)
[15:27] <jw4> mgz: no worries - nice chat :)
[15:28]  * perrito666 is told that amazon will actually ship ram to his country without the 1 month wait in customs and he grins
[15:28] <mgz> perrito666: real live rams?
[15:29] <perrito666> mgz: well, they will be alive when shipped
[15:36] <perrito666> rick_h_: btw, I loved the composition on rog/uros pic on your post
[15:37] <rick_h_> perrito666: ty :) was playing with my fancy lens during the sprint a lot
[15:58] <voidspace> anyone here familiar at all with gomaasapi ?
[15:59] <perrito666> voidspace: I have been around there but most likely dont hve enough info to help youi
[15:59] <voidspace> perrito666: :-)
[15:59] <voidspace> perrito666: I need to call the api to claim a static ip address
[15:59] <perrito666> voidspace: just ask the question and we can see
[15:59] <voidspace> I am doing...
[16:00] <voidspace> perrito666: I believe it looks like the following
[16:00] <voidspace> ipaddresses := environ.getMAASClient().GetSubObject("ipaddresses")
[16:00] <voidspace> _, err = ipaddresses.CallPost("", params)
[16:00] <voidspace> (response is not useful - either it succeeds or we get an error)
[16:00] <voidspace> perrito666: it's that empty string as the first argument to CallPost that bothers me
[16:00] <voidspace> perrito666: that's the "operation" parameter
[16:00] <voidspace> perrito666: but there's no operation here
[16:00] <perrito666> voidspace: ah I have dealt with it
[16:01] <voidspace> it's a post to the ipaddresses api end point
[16:01] <voidspace> perrito666: right - have you called any endpoints without operations?
[16:01] <perrito666> voidspace: you are dealing with a restful api there you not always have an op
[16:01] <voidspace> it looks odd
[16:01] <voidspace> perrito666: right
[16:01] <voidspace> I guess I have to try it :-)
[16:01] <voidspace> perrito666: I have a working maas server - I'll whip up some code to check it
[16:01] <voidspace> perrito666: thanks anyway
[16:02] <perrito666> voidspace: so iirc that translates to /path/to/node?operation
[16:02] <voidspace> perrito666: this particularcall is directly paddresses/
[16:03] <voidspace> no operation and no node id
[16:03] <perrito666> voidspace: ahh addresses yes, that one is specially ugly
[16:03] <perrito666> hold a sec, I was around there not long ago
[16:03] <voidspace> perrito666: ooh, I might be wrong
[16:03] <voidspace> perrito666: the GET is without an operation
[16:03] <voidspace> perrito666: looks like it's "reserve"
[16:03] <voidspace> POST /api/1.0/ipaddresses/ op=reserve
[16:04] <voidspace> my mistake then :-)
[16:04] <perrito666> voidspace: you did look at http://maas.ubuntu.com/docs/api.html#ip-addresses right?
[16:04] <voidspace> perrito666: I did...
[16:04] <voidspace> perrito666: I think I looked at the GET by mistake :-D
[16:04] <voidspace> just looked now and seen "reserve" is the op...
[16:04] <voidspace> perrito666: thanks
[16:05] <perrito666> voidspace: heh yes, happened to me too :p also there are a few with similar names so beware of not getting the wrong endpoint :p
[16:47] <katco> hey, go question: with a map, do you think it would be better to delete keys, or nil out their values? i would think that if the key had a good chance of being re-inserted, you'd want to nil out the value so the hash wouldn't continually be recomputed. thoughts?
[16:48] <mgz> katco: if it's not a giant map, I wouldn't worry about resizing
[16:49] <mgz> so, likely deleting makes better logical sense and is less likely to result in surprising bugs
[16:49] <katco> mgz: kind of thinking that as well
[16:49] <katco> mgz: b/c i would expect for people to be checking for "ok", not != nil
[16:50] <mgz> yup
[16:50] <katco> cool, ty sir!
[16:50] <katco> mgz: you've given me the confirmation bias that upholds my world-view! ;)
[16:52] <mgz> :)
[16:53] <natefinch> katco: definitely delete.  Don't prematurely optimize... just do the most simple and straightforward thing .
[16:54] <katco> natefinch: i recognize and applaud your agreement with me.
[16:54] <katco> natefinch: seriously, thanks for chiming in ;)
[16:55]  * natefinch is the king of chiming in. ;)
[16:55] <katco> haha
[18:24] <voidspace> g'night all
[18:59] <bodie_> if I find that I keep needing to repeat myself with methods like map recursion, or a conformer for map keys, I would normally extract these into a library and import it.  but, I don't know how I would handle this with juju
[18:59] <bodie_> I expect importing a personal library would be unkosher
[19:06] <bodie_> who could tell me where to put such things?  e.g. a method for coercing map[interface{}]interface{} to map[string]interface{}
[19:07] <bodie_> I'm kinda tempted just to open a PR with a personal import and see if it flies :S
[20:07] <bodie_> it looks like charm master breaks its own tests
[20:09] <bodie_> rogpeppe, config_test line 408: YAML error: reflect: reflect.Value.Set using unaddressable value
[20:09] <bodie_> maybe it's an issue with my deps
[20:10] <bodie_> doesn't seem to be
[20:13] <bodie_> https://github.com/juju/charm/pull/80 rogpeppe
[20:13] <bodie_> one-line fix
[20:13] <bodie_> not sure if this is how it *should* work, but it patches the breakage
[20:18] <bodie_> ah
[20:18] <bodie_> I see
[20:19] <bodie_> my charm master is out of sync with upstream because my upstream is gopkg.in/juju/charm.v4
[20:21] <rogpeppe> bodie_: oops. looks like juju-core needs latest version of yaml package
[20:21] <rogpeppe> bodie_: i think it should anyway - if you could do that, i'd be happy :)
[20:22] <rogpeppe> bodie_: i'm not here BTW :)
[20:22] <bodie_> rogpeppe, ack, so tweak the charm or the deps?
[20:22] <bodie_> er, rogpeppe's IRC away bot
[20:26] <mgz> heads up for juju-core... talking about server moving to systemd, which means our dynamically upstart jobs will need adapting for vivid
[20:27] <ericsnow> thumper: ping
[20:27] <thumper> ericsnow: hey
[20:28] <ericsnow> thumper: I've addressed just about everything on http://reviews.vapour.ws/r/346/
[20:28] <thumper> ericsnow: ok, will look again
[20:28] <ericsnow> thumper: left one open issue
[20:28] <ericsnow> thumper: thanks
[20:40] <thumper> ericsnow: was trying to look at the differences, and all I get is empty files and errors: http://reviews.vapour.ws/r/346/diff/16-17/?page=2
[20:40] <thumper> ericsnow: I'm assuming rb shouldn't do this?
[20:42] <ericsnow> thumper: it's because the branch depended on another branch
[20:42] <thumper> ah
[20:42] <thumper> ericsnow: ship it!
[20:42] <ericsnow> thumper: try diff'ing between 14 (where you last reviewed) and the latest
[20:42] <ericsnow> thumper: okay!
[20:57] <katco> well. i now know that my machine does not like spawning 100,000 instances of this test.
[21:00] <bodie_> heh
[21:01] <bodie_> my machine doesn't like running the juju core tests at all :/ I'm still trying to determine why I keep getting a reversed port number in the firewaller test
[21:03] <katco> i didn't expect it to become completely unresponsive... i thought the kernel scheduler was better than that
[21:03] <katco> 608s before it started giving me back control lol
[21:04] <katco> kind of. ugh.
[21:06] <katco> or gosh... maybe it's the window manager...
[21:07] <katco> ssh is working fine
[21:07] <katco> cpu and mem aren't under load...
[21:17]  * thumper goes to lie down for a bit
[21:32] <waigani> thumper/menn0: after I take out the machineID and NetworkName from the openPorts doc, what should the localID of the doc look like?
[21:33] <waigani> right now it is: "m#<machineid>#n#<networkname>
[21:34] <waigani> if we update the quires to use the fields, should we let the localID just be generated by mongo?
[21:34] <cmars> bodie_, i've seen that firewaller bug as well, intermittently
[21:34] <cmars> bodie_, is it fairly repeatable for you?
[21:35] <cmars> bodie_, what version go compiler are you using
[21:35] <bodie_> cmars, I wouldn't call it repeatable, but I've seen it I think three times now
[21:35] <bodie_> cmars, 1.3.3
[21:35] <cmars> bodie_, i'm using 1.3, and mgz just mentioned this could be a map ordering issue
[21:35] <waigani> thumper/menn0: just looking at how portsGlobalKey is used ...
[21:36] <bodie_> cmars, that might make sense.  should be a SameContents, perhaps
[21:36] <mgz> would explain why bot and others havenb't seen it, small maps are deterministically ordered on 1.2
[21:36] <mgz> one of you needs to file a bug :P
[21:40] <cmars> bodie_, firewallerSuite.TestGetMachinePorts ?
[21:41] <bodie_> cmars, aye
[21:41] <cmars> bodie_, i'll open it
[21:41] <bodie_> much appreciated cmars, I'm already way over EOD trying to get something else landed
[21:48] <ericsnow> thumper: when would be a good time to talk about MESS and backups?
[22:15] <waigani> thumper/menn0: machineid and networkname need to be in the id for the watcher
[22:16] <menn0> waigani: sorry, I don't actually know what you're doing
[22:16] <thumper> waigani: I didn't say to take them out of the id
[22:16] <thumper> waigani: just make sure they are also available outside the id
[22:16] <menn0> waigani: why did you want to remove machineID and NetworkName from the openPorts doc?
[22:16] <waigani> thumper: right
[22:16] <thumper> like the envuuid
[22:16] <waigani> menn0: I misunderstood
[22:16] <menn0> ok
[22:22] <rogpeppe> bodie_: tweak juju-core deps
[22:24] <katco> wallyworld: "This webpage has a redirect loop"
[22:24] <katco> not sure what's going on
[22:24] <wallyworld> :-(
[22:24] <wallyworld> i'l try opening hangout again
[22:25] <katco> wallyworld: i bet this is that stupid cookies issue i was having
[22:25] <mgz> don't eat the stupid cookies!
[22:25] <wallyworld> chocolate chip?
[22:26] <ericsnow> perrito666: FYI, all four of those patches have now landed
[22:26] <perrito666> ericsnow: niiice, Ill start integration right away
[22:54] <menn0> thumper: how do you feel about NewEnvironment's signature changing from this:
[22:54] <menn0> NewEnvironment(env, server names.EnvironTag, owner names.UserTag, name string) (*Environment, error)
[22:54] <menn0> to this:
[22:54] <menn0> NewEnvironment(cfg *config.Config, server names.EnvironTag, owner names.UserTag, ownerPassword string) (*Environment, error)
[22:55] <thumper> so it creates an environment uuid?
[22:55] <thumper> why have ownerpassword?
[22:55] <thumper> and why remove the name?
[22:56] <menn0> the name comes from the config
[22:56] <menn0> ownerpassword is needed to set up the owner user
[22:56] <menn0> the uuid also comes from the config
[22:56] <menn0> thumper: ^
[22:56] <thumper> the owner must already exist
[22:57] <menn0> you're right
[22:57] <menn0> createInitialUserOp should only be done by Initialize and not by NewEnvironment
[22:57] <menn0> i'll fix that
[22:58] <thumper> perhaps, remove the server, and just add a comment that the environment will have the same server as the initial environment
[22:58] <thumper> the server uuid was added to enable us to store records to remote environments
[22:58] <thumper> which we have no use case for right now
[22:58] <thumper> maybe soon with cross environment relations
[22:58] <thumper> which will need other commands anyway
[22:58] <thumper> so...
[22:58] <menn0> that makes sense
[22:59] <thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, error)
[22:59] <thumper> or
[22:59] <thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, *State, error)
[22:59] <menn0> I was wondering about returning the new state
[22:59] <thumper> so it returns a *State that would operate in that env?
[22:59] <menn0> but it's easy to get with State.ForEnviron
[23:00] <thumper> sure
[23:00] <menn0> and NewEnvironment doesn't need to create it itself
[23:00] <menn0> so it's probably outside its responsibility to return it
[23:03] <menn0> thumper: thanks I'll run with this
[23:03] <thumper> ok
[23:03] <thumper> cool
[23:03] <thumper> alexisb: are we meeting today?
[23:04] <alexisb> yes
[23:05] <thumper> k, be there in a sec
[23:12] <wallyworld> thumper: when you finished your meeting, i need to talk about bug 1392745
[23:12] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[23:12] <thumper> :-(
[23:58] <wallyworld> anastasiamac: review done, let me know if you have questions