=== thumper-gym is now known as thumper
[01:34] <axw> thumper: I have a couple more small sshstorage MPs, if you have time to look
[01:34] <axw> also, good morning
[01:40] <thumper> axw: sure, line them up
[01:40]  * davecheney waves
[01:44] <davecheney> % env LD_LIBRARY_PATH=/opt/gccgo/lib64 ./juju version
[01:44] <davecheney> 1.15.0-raring-amd64
[01:46] <axw> thumper: https://code.launchpad.net/~axwalk/juju-core/sshstorage-put-stdin/+merge/186936
[01:46] <axw> then https://code.launchpad.net/~axwalk/juju-core/sshstorage-tmpdir-default/+merge/186939
[01:46] <axw> thanks
[01:47] <axw> davecheney: cool :)
[01:48] <davecheney> axw: lots of little edge cases
[01:49] <davecheney> but they are around building gccgo
[01:49] <davecheney> nothing to do with juju-core
[01:50] <davecheney> wallyworld_: juju _STILL_ waits too long before telling you that your environment is already bootstrapped
[01:50] <davecheney> http://paste.ubuntu.com/6143764/
[01:50] <davecheney> worse, it happily overwrites tools, then notices your env is bootstrapped
[01:50]  * axw wonders how much of juju llgo can build
[01:51] <wallyworld_> davecheney: i never did any work on the "waits too long" bug
[01:51] <wallyworld_> i was doing work on simplestreams
[01:51] <davecheney> ok
[01:51] <davecheney> should I raise an issue
[01:51] <wallyworld_> but fwiw i agree with you
[01:51] <wallyworld_> yes
[01:51] <wallyworld_> mark it high i reckin
[01:51] <davecheney> ok, will do
[01:52] <wallyworld_> maybe i can get to it this week
[01:52] <wallyworld_> still have simplestreams mirrors and checksum support to finish
[01:53] <davecheney> done
[01:53] <davecheney> kk
[02:04] <thumper> axw: can we talk about this change?
[02:04] <thumper> I have a few questions
[02:04] <thumper> probably faster in a hangout
[02:04] <axw> yes, just a sec
[02:04]  * thumper waits
[02:05] <axw> thumper: https://plus.google.com/hangouts/_/d485a58f42c7e12792ce53c161e010a0775851a8?authuser=1&hl=en
[02:52] <axw> wallyworld_: your MP from the other day fixes this, right? https://bugs.launchpad.net/juju-core/+bug/1223224
[02:53] <wallyworld_> looking
[02:53] <wallyworld_> yes indeed
[02:53] <wallyworld_> and errors
[02:53] <wallyworld_> thumper did the work, i just added a test and landed
[02:54] <wallyworld_> i'll link the branch
[02:54] <axw> yeah, we had a chat, I was a bit confused when I saw it come from you :)
[02:54] <axw> cool thanks
[02:55] <axw> I'll assign the card in LeanKit to you and move it to merged if that's ok
[02:55] <axw> or thumper
[02:55] <axw> rather
[02:56] <wallyworld_> sure, doesn't really matter
[02:56] <thumper> nah, it's done now
[02:56] <thumper> :)
[02:56] <wallyworld_> so long as it's in merged
[02:56] <wallyworld_> if it is in merged, it will be added to the release notes
[02:57] <wallyworld_> s/will be/should be perhaps
[02:57] <axw> yup
[02:57] <axw> done
[02:58] <thumper> school run, back shortly
[04:41]  * thumper disconnects to head to ice-skating
[04:41] <thumper> caitlin is skating
[04:41] <thumper> I'm going to be working in the cold
[04:42]  * thumper just proposes a fix to a fix
[04:42] <thumper> tests still passed, but wasn't as clean as it should be
=== tasdomas_afk is now known as tasdomas
[06:41] <rogpeppe> mornin' all
[06:42] <rogpeppe> axw: hiya
[06:42] <axw> rogpeppe: howdy
[06:43] <rogpeppe> axw: i'm looking for a review on this. i reckon you might like it. https://codereview.appspot.com/13249054/
[06:43] <axw> okey dokey, looking
[06:46] <jam> morning rogpeppe and axw
[06:46] <rogpeppe> jam: hiya
[06:46] <axw> heya jam
[06:48] <rogpeppe> jam: you might want to take a look too. i had some spare time over the weekend and thought it was worth doing.
[06:49] <jam> rogpeppe: from the overview, I'm happy to not have the "Discarded" stuff going into the log. Having it at Trace level might be ok
[06:49] <rogpeppe> jam: i'm happy for it to be silent, tbh
[06:50] <rogpeppe> jam: this now means that the decision can be made externally
[06:50] <jam> rogpeppe: I would be ok with a flag to somehow enable it, just because of the "why isn't this method being detected" it could be helpful for developement. But it serves no purpose in production.
[06:50] <rogpeppe> jam: see https://codereview.appspot.com/13827043/
[06:51] <rogpeppe> jam: with that, you'll get a test failure if you add a method that's not detected
[06:52] <rogpeppe> jam, axw: here's an exploration of a potentially interesting idea that this enables. it only took an hour or so after i thought of the idea: http://paste.ubuntu.com/6143236/
[06:53] <rogpeppe> jam, axw: it generates API client code for the whole API
=== mthaddon` is now known as mthaddon
[06:53] <rogpeppe> jam, axw: (the output looks like this: http://paste.ubuntu.com/6143244/ )
[06:54] <axw> rogpeppe: nice
[06:55] <rogpeppe> axw: text/template was a perfect match for the problem - i only made a single tweak to the rpcreflect API to make it easier to use (make a method return (Method, error) rather than (Method, bool)
[06:56] <rogpeppe> )
[07:38] <rogpeppe> TheMue: mornin'
[07:38] <TheMue> rogpeppe: good morning
[07:39] <TheMue> rogpeppe: just scanning the mail from friday till today
[07:40] <TheMue> rogpeppe: what's weird, i've got a pre-filtering to sort it a bit. it mostly works, but sometimes mail still lands in the inbox
[07:40] <davecheney> TheMue: from the driver guys ?
[07:41] <TheMue> davecheney: this, but also other mails. i think it depends on replys and the threading. while the first mail is sorted correctly a reply lands in the inbox and so the whole thread
[08:25] <fwereade> mgz, ping
[08:30] <jam> fwereade: I often don't see him around yet, anything I can help with?
[08:30] <jam> good morning, btw
[08:33] <jam> rogpeppe: so to come back to your "auto-generate the client side of the API", one caveat with what you've written is that everything is exposed as a Params object, but if you actually look at state/api/client.go we expose functions that have variables that hide the internal Params object.
[08:33] <jam> For example, your auto-generated one does: DestroyRelation(p params.DestroyRelation)
[08:33] <jam> while the existing one is: DestroyRelation(endpoints ...string)
[08:34] <rogpeppe> jam: yes, that is of course an issue.
[08:34] <jam> I'm pretty sure we wanted API clients to generally think in terms of "just a function call" rather than dealing with the params struts.
[08:34] <jam> structs.
[08:34] <rogpeppe> jam: but i don't really know how much of an issue it is in practice. most API calls are used in just one or two places.
[08:35] <jam> rogpeppe: well, I think it made it easy to transition from state.State access to api.State access
[08:35] <jam> since the func args are relatively the same.
[08:35] <rogpeppe> jam: yes, it did.
[08:35] <rogpeppe> jam: there's no question that the current api state client adds some value.
[08:36] <rogpeppe> jam: one possibility is to make the current api state clients call the auto-generated code
[08:36] <rogpeppe> jam: which actually has a few advantages, i think - for one it's type safe
[08:36] <jam> rogpeppe: given the sum total of current API client code is "wrap the args into a Params and pass it to Call" it doesn't seem to gain us much
[08:37] <rogpeppe> jam: and for another, we get an interface type that we can mock
[08:37] <jam> rogpeppe: well we can mock the "State" object today, because it is just a "common.Caller"
[08:42] <rogpeppe> jam: you're maybe right that it isn't worth doing, but i think it's worth considering - i'm not really sure that the current API client code pulls its weight - it's a thin shim with a tiny bit of local state.
[08:45] <rogpeppe> jam: my motivation for thinking about this was: why is our api code so big (> 17000 lines including tests) when all it is is a relatively thin layer on top of the existing mongo state code?
[08:46] <jam> rogpeppe: so searching for mongo error codes (another patch of yours) I did find: https://github.com/mongodb/mongo/blob/master/docs/errors.md
[08:46] <jam> i
[08:46] <jam> interestingly, 10057 is remarked as a Code, but no comment as to what it means :)
[08:46] <jam> and the link takes you to a code page that isn't that code
[08:47] <rogpeppe> awesome!
[08:47] <jam> so it does seem to list and describe them, but the doc itself is pretty out of date for the "code" links :)
[08:48] <rogpeppe> jam: from one point of view, all our agent API calls are internal.
[08:50] <rogpeppe> jam: and your example is actually a interesting one - there is exactly *one* call to DestroyRelation in the non-test code. is it *really* worth the extra layer for the convenience of the variadic arguments?
[08:52] <rogpeppe> jam: anyway, i'm not suggesting that we do this right away, just that it's something worth thinking about
[08:58] <rogpeppe> fwereade: it would be nice if you could take a look at this too, please:  https://codereview.appspot.com/13249054/
[08:58] <fwereade> rogpeppe, sure, cheers
[08:59] <rogpeppe> fwereade: (my spare time became slightly more copious in the weekend :-])
[08:59] <fwereade> rogpeppe, ha, that's always nice :)
[09:10] <fwereade> rogpeppe, LGTM, that's really nice
[09:10] <rogpeppe> fwereade: cool, thanks
[09:10] <fwereade> rogpeppe, I think it made things more readable too
[09:10] <fwereade> rogpeppe, but I think we should include the name in the error ;p
[09:11] <rogpeppe> fwereade: yeah, i think it made the structure better. there's actually another branch in waiting adds rpcreflect.Value that implements Call
[09:11] <fwereade> rogpeppe, stuttery messages are bad, but less bad than useless messages
[09:12] <fwereade> rogpeppe, I'd rather risk the former when we don't control the clients in-package
[09:12] <rogpeppe> fwereade: originally it returned bool
[09:12] <rogpeppe> fwereade: i don't think the current error is worse than that
[09:13] <rogpeppe> fwereade: but, fair enough, i'll make it return a NotFoundError
[09:13] <fwereade> rogpeppe, heh, I find a bool less bothersome than a half-specified error
[09:13] <rogpeppe> fwereade: it's not half-specified!
[09:13] <fwereade> rogpeppe, with a bool it's totally clear that interpretation of the result is on the client
[09:14] <rogpeppe> fwereade: i suppose so. but the docs do make that clear.
[09:14] <rogpeppe> fwereade: and there are lots of other precedents for static error values which work ok
[09:14] <rogpeppe> fwereade: e.g. io.EOF
[09:15] <fwereade> rogpeppe, I *think* that the possibility of other errors is what makes the static error value a cromulent choice
[09:16] <rogpeppe> fwereade: in this case there's no possibility of other errors, as documented
[09:16] <fwereade> rogpeppe, in such cases, I think I like bools myself...
[09:16] <fwereade> rogpeppe, but, eh -- it' somewhat academic anyway, because we certainly do control the client at the moment
[09:17] <rogpeppe> fwereade: i only made the change so that i could do this more easily: http://paste.ubuntu.com/6143236/
[09:17] <rogpeppe> fwereade: which was a little experiment
[09:18] <rogpeppe> fwereade: to see how easy it might be to generate the client API code automatically
[09:18] <fwereade> rogpeppe, that's interesting, indeed
[09:18] <rogpeppe> fwereade: this is what the output looks like: http://paste.ubuntu.com/6143244/ )
[09:19] <rogpeppe> fwereade: it compiles but i haven't tried using it
[09:19] <fwereade> rogpeppe, cool
[09:20] <fwereade> rogpeppe, anyway I do not think I am adding value by quibbling over the perfect return for the method :)
[09:20] <fwereade> rogpeppe, follow your heart
[09:20] <rogpeppe> fwereade: thanks. i did originally consider both possibilities - this is what my heart said :-)
[09:21]  * fwereade had maybe better go buy tobacco,I have a feeling shops close at 12 here
[09:21] <rogpeppe> fwereade: where are you?
[09:22] <fwereade> rogpeppe, we moved to st pauls bay
[09:22] <fwereade> rogpeppe, less city, more towny
[09:22] <rogpeppe> fwereade: ah
[09:33] <rogpeppe> "
[09:33] <rogpeppe> I'm ok with a blacklist, but we might just want a whitelist test. (both?) and
[09:33] <rogpeppe> then when you add something you update the lists.
[09:33] <rogpeppe> "
[09:33] <rogpeppe> jam: i'm not quite sure what you mean there
[09:33] <rogpeppe> jam: it isn't a blacklist, by my understanding of the word
[09:34] <rogpeppe> jam: although are you suggesting that i do what i mentioned in the CL description?
[09:44] <jam> rogpeppe: it is a list of the entries that shouldn't be exposed, vs a list of entries that *should* be exposed
[09:45] <rogpeppe> jam: well, really it's a whitelist of entries that we allow to be ignored
[09:45] <jam> interestingly, one could argue that you should test that all of them *are* ignored, so the list doesn't grow stale.
[09:45] <rogpeppe> we do that
[09:46] <rogpeppe> jam: if you add another method that is ignored, the test will fail
[09:46] <jam> rogpeppe: sure, I'm actually saying the inverse, if you remove a method that was previously ignored, but you're doing an exact match
[09:46] <rogpeppe> jam: (that's why i don't think of it as a blacklist)
[09:46] <jam> not iterating over them and looking them up as a set
[09:47] <jam> rogpeppe: one could argue that we could do both sides as exact matches
[09:47] <rogpeppe> jam: i agree with that
[09:47] <rogpeppe> jam: it's a little bit more work when adding API calls, but probably worth it
[09:47] <jam> it does add slightly more to the effort to expose a new name
[09:48] <jam> were I doing it today, I probably would, but I don' think we have to worry too much
[09:48] <rogpeppe> jam: we could easily have a trivial program that auto-generated the list
[10:04] <jam> mgz: poke?
[10:07] <mgz> jam: ey
[10:09] <mgz> fwereade: what were you after earlier?
[10:14] <rogpeppe> fwereade, jam: this factors out a little more logic from rpc to rpcreflect: https://codereview.appspot.com/13778046/
[10:26] <fwereade> mgz, hey, I was wondering about how the get-a-new-address thing ties into the environs interface
[10:26] <fwereade> mgz, a method on Instance?
[10:27] <fwereade> mgz, actually, can we chat after the standup please? I have food to eat quickly
[10:27] <mgz> fwereade: sure
[10:28] <mgz> I was thinking an environ operation still
[10:43] <fwereade> mgz, at the moment, maas does it by magic hackery, right?
[10:46] <jam> standup time https://plus.google.com/hangouts/_/6f82d7382f19fc7b18493254974fb66ed1b99244
[10:47] <jam> mgz: ^^
[10:47] <jam> dimitern: ^^
[10:47] <rogpeppe> dimitern: ^
[11:22] <natefinch> mgz, and whoever else: https://pastebin.canonical.com/97850/
[11:22] <mgz> ta
[11:23]  * TheMue => lunch
[11:23] <mgz> missing a number natefinch?
[11:23] <mgz> doh, canonical
[11:24] <mgz> "state or API addresses not found in configuration"
[11:25] <natefinch> yeah, saw that... but I don't know what it means or how to fix it
[11:26] <natefinch> I tried looking for that string in the sourcecode, but it only seems to appear in tests
[11:33] <mgz> natefinch: comes from l326 agent/agent.go
[11:34] <natefinch> mgz: oh, I see, that's why I couldn't find it
[11:35] <natefinch> mgz: doesn't really tell me how it got in the bad state or how to fix it though.  What configuration is it talking about?
[11:36] <mgz> something odd has happened with the agent config, it seems to not producing the format it claims
[11:37] <mgz> or, actually, it seems okay... fun fun
[11:38] <mgz> rog is trying some debugging
[11:38] <mgz> natefinch: are you trying with trunk, or a slightly older version?
[11:39] <natefinch> mgz: it's a branch from last week that hasn't been updated from trunk. I could update from trunk if you think that'll help
[11:40] <mgz> it would make reasoning about it a little less fraught, but only if it doesn't take you too long to do
[11:40] <natefinch> mgz: easy enough
[11:45] <natefinch> mgz: done, bootstrapping a new environment
[11:46] <mgz> natefinch: when it's up, if you have the same error, can you check the contents of /var/lib/juju/agents/bootstrap/agents.conf
[11:46] <natefinch> mgz: will do
[11:55] <rogpeppe> natefinch: actually, please check the entire contents of that directory
[11:55] <rogpeppe> natefinch: /var/lib/juju/agents/bootstrap, that is
[11:55] <rogpeppe> natefinch: i suspect that there might not be a "format" file there
[11:56] <rogpeppe> natefinch: but if there is, it'll blow that theory out of the water
[11:56] <natefinch> mgz, rogpeppe: finally was able to log in... there's a format file there
[11:56] <rogpeppe> natefinch: bugger
[11:57] <natefinch> mgz, rogpeppe: agent.conf - http://pastebin.ubuntu.com/6145223/
[11:57] <rogpeppe> natefinch: could you try executing the command line on line 414
[11:58] <natefinch> (and yes, it got the same error)
[11:58] <rogpeppe> natefinch: (you'll need to re-quote it)
[11:58] <natefinch> rogpeppe: line 414 of what?
[11:59] <rogpeppe> natefinch: one mo
[11:59] <rogpeppe> natefinch: this command: http://paste.ubuntu.com/6145226/
[12:00] <mgz> natefinch: I think you'll need to elevate to do that
[12:00] <rogpeppe> +1
[12:00] <natefinch> mgz: yeah, it told me so :)   I get the same error
[12:00] <natefinch> state or API addresses not found in configuration
[12:01] <mgz> good good
[12:01] <rogpeppe> natefinch: yay!
[12:01] <rogpeppe> natefinch: (kinda)
[12:01] <natefinch> heh
[12:01] <natefinch> reproducibility is good, even if you don't yet know how to fix it
[12:01] <rogpeppe> natefinch: is this machine accessible from outside?
[12:01] <rogpeppe> natefinch: i.e. can i ssh into it?
[12:04] <natefinch> I think you have to ssh into garage maas (maas.mallards) first and then you can ssh into the node that is running the virtual maas, maas-1-01
[12:05] <rogpeppe> natefinch: ok, different approach: can you compile this program, scp it to the node and try running it? http://paste.ubuntu.com/6145248/<
[12:05] <frankban> juju devs: maybe I have something wrong with my local configuration, but it seems that juju-core trunk does not execute the config-changed hook when using "juju set" to change charm options. "juju debug-log" also seems to no longer show hooks output. Reverting to an older revision of core (e.g. 1790)  everything restarted to work as usual... thoughts?
[12:06] <rogpeppe> frankban: hmm, sounds bad
[12:06] <rogpeppe> fwereade: any idea?
[12:07] <frankban> rogpeppe: yeah, but it is possible that it is some configuration problem on my side, could you please try to reproduce?
[12:08] <mgz> frankban: what are you doing to run into this exactly?
[12:08] <rogpeppe> frankban: will do. what charm were you seeing the problem with?
=== gary_poster is now known as gary_poster|away
[12:09] <frankban> rogpeppe: juju-gui. mgz: deploy juju-gui, start debug-log, then change an option (e.g. juju set builtin-server=true).
[12:09] <natefinch> rogpeppe: I get a nil error as long as I run elevated (otherwise permission denied opening agent.conf)
[12:10] <rogpeppe> natefinch: did you upload-tools ?
[12:10] <frankban> rogpeppe: the GUI correctly shows the option changed (so I guess the new value is correctly sent by the megawatcher). but ISTM that the hook is never called
[12:11]  * frankban lunches
[12:12] <natefinch> rogpeppe: yeah.  Let me make sure my process is correct.  I don't have a build environment on the maas virtual server, so I'm just building juju and jujud locally and copying them up to the server, then running bootstrap --upload-tools, which finds the jujud I copied up there
[12:12] <rogpeppe> natefinch: what does jujud version print?
[12:13] <natefinch> rogpeppe:  oh hmm... interesting... 1.15.0-raring-amd64
[12:13] <natefinch> raring I'm guessing is the problem
[12:13] <natefinch> (my dev environment is raring)
[12:14] <natefinch> and the nodes are precise
[12:15] <rogpeppe> natefinch: what's in /etc/lsb-release ?
[12:15] <rogpeppe> natefinch: i think your node must be raring actually
[12:16] <natefinch> rogpeppe: the nodes are definitely precise, just double checked lsb-release
[12:16] <rogpeppe> natefinch: could you paste the output of "du -a /var/lib/juju" please
[12:16] <natefinch> rogpeppe: the maas host where juju is running is raring though
[12:17] <rogpeppe> natefinch: ah, sorry, i thought that's what you were talking about
[12:17] <natefinch> rogpeppe: sorry, my terminology may not be great.  Yes, the host is raring, the nodes inside maas are precise
[12:19] <natefinch> rogpeppe: du returns this on the bootstrap node: http://pastebin.ubuntu.com/6145289/
[12:19] <rogpeppe> natefinch: what's in /var/lib/juju/tools/1.15.0.1-precise-amd64/FORCE-VERSION ?
[12:20] <natefinch> rogpeppe: 1.15.0.1
[12:21] <rogpeppe> natefinch: where is your shell finding jujud?
[12:21] <rogpeppe> natefinch: i.e. what does "which jujud" print?
[12:22] <natefinch> rogpeppe: which jujud on the bootstrap node doesn't find anything
[12:22] <rogpeppe> natefinch: so how did you run it?
[12:22] <natefinch> rogpeppe: oh sorry, I was running that previously on the maas host...
[12:23] <natefinch> rogpeppe: thought you just wanted the version of what was getting uploaded
[12:24] <rogpeppe> natefinch: that's fine, np
[12:24] <rogpeppe> natefinch: that tiny source file i just pasted you: did you compile that against exactly the same juju source as the one you uploaded with --upload-tools ?
[12:25] <natefinch> yep
[12:25] <rogpeppe> weirdness
[12:26] <natefinch> rogpeppe: I have to make a phone call, can  we pick this up in a bit?  Sorry... it's time sensitive
[12:26] <rogpeppe> natefinch: np
=== gary_poster|away is now known as gary_poster
[12:28] <rogpeppe> natefinch: ok, when you're back, could you try this: cd $GOPATH/cmd/jujud; go build; scp jujud $MY_MAAS_NODE
[12:29] <rogpeppe> natefinch: then on the maas node, try running that just-uploaded jujud binary with the same args as in this paste: http://paste.ubuntu.com/6145226/
[12:29] <rogpeppe> natefinch: (just to sanity check that we can reproduce the problem directly)
[12:45] <rogpeppe> mgz: for(i in `{go list -f '{{.Dir}}' ./...}){src=$i/*.go; if(grep -l 'launchpad.net/gocheck' $src > /dev/null&& ! grep -l 'gc\.TestingT' $src> /dev/null){echo $i}}
[12:45] <rogpeppe> :-)
[12:46] <mgz> chaos!
[13:02] <rogpeppe> mgz: this works better. more chaos; love them one-liners :-) for(i in `{go list -f '{{.Dir}}' ./...}){if(! ~ $i *testing){src=$i/*.go; if(grep -q -l 'launchpad.net/gocheck' $src && ! egrep -l -q 'gc\.TestingT|testing\.MgoTestPackage' $src){echo foo $i}}}
[13:04] <sinzui> rock! Next time someone says my sed lines are impossible, I'll point them the rogpeppe's bash
[13:04] <rogpeppe> sinzui: it's not bash
[13:05] <sinzui> Even better go emulating bash
[13:08] <rogpeppe> sinzui: not quite
[13:09] <rogpeppe> sinzui: it's rc actually
[13:09] <rogpeppe> sinzui: which is considerably simpler than bash though you wouldn't guess it from that snippet :-)
[13:09] <sinzui> :)
[13:18] <natefinch> rogpeppe:  that ran without error.  maybe I accidentally uploaded an old jujud?  I can retry bootstrap with the new jujud
[13:19] <mgz> natefinch: I think upload-tools can sometimes surprisingly pick something other than what you intended
[13:19] <rogpeppe> natefinch: do you still have the executable that you wanted upload-tools to upload?
[13:20] <natefinch> rogpeppe: I just overewrote it :/
[13:21] <rogpeppe> mgz: https://codereview.appspot.com/13321052
[13:21] <rogpeppe> natefinch: ok, so...
[13:22] <rogpeppe> natefinch: i think you need to try again
[13:23] <rogpeppe> natefinch: so bootstrap with an executable that you've built against trunk, verify that the problem happens.
[13:23] <rogpeppe> natefinch: then md5sum the binary at both sides and see if it matches
[13:24] <rogpeppe> natefinch: oh yes
[13:24] <rogpeppe> natefinch: please bootstrap with --debug
[13:24] <natefinch> yep
[13:24] <rogpeppe> natefinch: because --upload-tools *might* print the path of the binary it's found, which might not be what you're expecting
[13:25] <natefinch> rogpeppe:  it does.  it's getting the right one (it checks $HOME, looks like)
[13:39] <natefinch> rogpeppe, mgz: and now it works fine.  Feh.  I swear I did the exact same thing last time... but evidently something was out of sync.
[13:46] <mgz> natefinch: best guess is you maybe didn't run go install .... the upload-tools logic here is frustratingly tricky
[13:47] <natefinch> mgz: shouldn't have been the problem, since I wasn't running upload-tools in my dev environment... anyway, it was obviously a problem of jujud being out of sync.
[13:55] <natefinch> fwereade: FWIW in initial testing, maas-tags are working great.  I want to do some more testing around edge cases and stuff, but so far so good
[14:08] <sinzui> mgz, ping
[14:08] <natefinch> rogpeppe, mgz, jam:  what's the expected behavior if you specify constraints that can't be met?
[14:08] <mgz> expected, or desired?
[14:08] <mgz> you get no machine :)
[14:08] <rogpeppe> you should see something in the status
[14:09] <natefinch> mgz: what is juju right now coded to do?  Trying to make sure there's no bugs when you fail to match tags
[14:09] <natefinch> rogpeppe: ok
[14:35] <frankban> rogpeppe: any news on the error I reported?
[14:36] <rogpeppe> frankban: sorry, i haven't had a look
[14:36] <frankban> rogpeppe: np
[14:36] <rogpeppe> frankban: please file a bug!
[14:36] <rogpeppe> frankban: and i'll try to make time to have an investigate
[14:37] <frankban> rogpeppe: ok, I'll try again, removing binaries, and then file a bug
[14:37] <fwereade> natefinch, sorry, missed you
[14:37] <rogpeppe> fwereade: did you see about frankban's problem above?
[14:38] <frankban> rogpeppe: is " godeps -u dependencies.tsv" the right thing to do to set up the deps?
[14:38] <fwereade> natefinch, jam, rogpeppe: btw you all seem to have positively reviewed branches not landed
[14:38] <fwereade> rogpeppe, frankban, I did not, I shall scroll back
[14:38] <rogpeppe> fwereade: i'm waiting for at least one branch to land
[14:38] <fwereade> natefinch, that is awesome news
[14:38] <fwereade> natefinch, thank you very much
[14:38] <fwereade> rogpeppe, sweet
[14:40] <fwereade> rogpeppe, frankban: I have no immediate input on the problem -- did someone repro, or not?
[14:41] <rogpeppe> fwereade: i haven't tried yet
[14:41] <frankban> fwereade: not yet, retrying and then filing a bug
=== tasdomas is now known as tasdomas_afk
=== tasdomas_afk is now known as tasdomas
=== tasdomas is now known as tasdomas_afk
[15:28] <natefinch> this makes me sad: $ juju help constraints        ERROR unknown command or topic for constraints
[15:43] <rogpeppe> natefinch: file a bug
[15:56] <natefinch> rogpeppe: I will.
=== natefinch is now known as natefinch-afk
[16:14] <fwereade> is anyone au fait with the latest state of upload-tools wrt simplestreams?
[16:15] <rogpeppe> fwereade: i'm not, sorry
[16:35] <frankban> fwereade, rogpeppe: filed bug 1229286
[16:35] <_mup_> Bug #1229286: debug-log and boolean options are broken in trunk <juju-core:New> <https://launchpad.net/bugs/1229286>
[16:35] <rogpeppe> frankban: is it just boolean options?
[16:35] <frankban> rogpeppe: it seems so
[16:35] <frankban> it seems they are always false
[16:36] <rogpeppe> frankban: TheMue has been dealing with setting issues recently and might know more about this
[16:39] <frankban> rogpeppe: I was trying to set a boolean option to true and it was not working and, since no output was printed in debug-log, I suspected the hook was not executed. But then I was able to successfully change a string option. As I wrote in the bug description, those are likely to be two different problems.
[16:39] <frankban> or maybe a problem in my local devenv
[16:39] <rogpeppe> frankban: i think it's probably all related to a single problem around boolean flags
[16:40] <frankban> rogpeppe: cool
[16:40] <rogpeppe> frankban: that logic has changed recently, i believe
[16:40] <frankban> rogpeppe: as I mentioned in the bug revno 1750 works well
[16:41] <rogpeppe> frankban: have you bisected between then and now?
[16:41] <frankban> rogpeppe: no I don't, just taken a revision near the latest stable release
[16:41] <rogpeppe> frankban: ok, thanks
[16:55] <mgz> sinzui: the 1.14.1 release anouncement seems a little wonky
[16:56] <sinzui> yeah 1.14.1 is replacing 1.14.0
[16:56] <mgz> says it replaces 1.14.1, and the resolved issues list looks wrong
[16:56]  * sinzui repllies
[16:59] <sinzui> mgz. I was told/interpreted the instructions for a replacement release to re-list the issues
[16:59] <mgz> fair enough, seems a little odd not to mention the openstack security group fix though
[17:19] <utlemming> is there a way to bootstrap juju with out a tty?
[17:24] <mgz> sure, write "juju bootstrap" in a text file, make it excutable, then double click it in your shell
[17:25] <mgz> or did you want a less silly answer? the juju-gui can do a lot of management, I'm not sure what their easy setup plans are.
=== natefinch-afk is now known as natefinch
[18:02] <rogpeppe> natefinch, fwereade, jam, dimitern, mgz: some provider/dummy updates. https://codereview.appspot.com/13594044
[18:02] <rogpeppe> and that's me for the day
[18:03] <rogpeppe> g'night all
[18:03] <natefinch> rogpeppe: g'night. I'll take a look
[18:25] <fwereade> utlemming, the only other option is to write your own go code to invoke juju
[18:31] <natefinch> smoser: any reason you can think of that I might not be able to ssh into the nodes in my maas environment after the host rebooted?  I double checked, and resolv.conf is still set up correctly.  ssh just hangs forever not being able to connect
[19:20] <sinzui> natefinch, do you know what runs the juju-core test suite for merges? What machine?
[19:20] <natefinch> sinzui: no idea, sorry
[19:20] <sinzui> okay
[19:39] <smoser> natefinch, hold on
[21:04] <thumper> mramm: ping
[21:24] <mramm> thumper: pong
[21:24] <mramm> sorry, got caught in another meeting
[21:25] <thumper> mramm: still want to chat
[21:25] <mramm> sure, yea
[23:24] <wallyworld_> sinzui: i just read the backscroll, the juju-core landing bot is 10.55.32.52
[23:24] <wallyworld_> it's an instance on canonistack