[00:48] <thumper> axw: hey there
[00:49] <thumper> axw: sinzui_ is having issues with your hp fix branch, seems to have a bad import
[00:52] <axw> thumper: reading the email now
[00:53] <axw> eh wtf
[00:54] <axw> aw crap, I think I enabled goimports and it mucked about with the imports
[00:55] <thumper> heh
[00:55] <thumper> axw: so, after talking with fwereade this morning, I'm going to implement a system ssh key right now
[00:55] <axw> thumper: excellent
[00:56]  * axw feels vindicated
[00:56] <axw> ;)
[00:56] <thumper> davecheney: I don't suppose your ssh go stuff has keygen?
[00:59] <axw> thumper: AFAIK they
[00:59] <axw> are just PEM keys
[01:00] <thumper> axw: I'm not entirely sure what that means
[01:01] <axw> thumper: same format used by the private keys we generate already
[01:01] <axw> for mongo
[01:01] <thumper> oh?
[01:01] <thumper> hmm...
[01:02] <axw> thumper: in fact, we could perhaps just use the same one
[01:02] <thumper> axw: maybe...
[01:02] <axw> not sure what the requirements are for SSH
[01:02] <thumper> yeah, well luckily I have another machine here I can ssh to to test
[01:03] <davecheney> thumper: it wouldn't be hard to write
[01:04] <thumper> davecheney: yeah, axw said as much
[01:04] <thumper> I think what I'd like is a function in utils/ssh called "GenerateKey" (surprise)
[01:04] <thumper> that generates to byte arrays,
[01:05] <thumper> one private key and one public key
[01:05] <thumper> equivalents of "id_rsa" and "id_rsa.pub"
[01:05] <thumper> given the core go team's affinity for crypto
[01:05] <thumper> chances are all I need is glue
[01:06] <davecheney> yup
[01:06] <davecheney> lemmie look in the ssh package tests
[01:06] <davecheney> we probably have some code
[01:07] <thumper> davecheney: awesome sauce
[01:07]  * thumper channels fwereade
[01:31] <thumper> davecheney: found any? I've found some docs as to the file format, so could hack something up
[01:31] <thumper> davecheney: but you sould probably be saving me time
[01:36] <davecheney> thumper: yup
[01:36] <davecheney> looking after lunch
[01:43] <thumper> ok
[01:43] <thumper> ta
[01:47] <axw> thumper: I'm just looking to see if we can reuse the existing private key we have
[01:47] <axw> there's code in go.crypto/ssh to generate an authorized_keys line from an RSA public key
[01:55] <axw> thumper: https://gist.github.com/axw/8016123
[01:56] <thumper> axw: what about the identity file that you can hand off to ssh?
[01:57] <axw> thumper: I just fed in the key we give to mongo, added the output of that program to ~/.ssh/authorized_keys, and used ssh -i local-private-key.pem
[01:57] <axw> thumper: it's just the key file
[01:57] <thumper> axw: and that works?
[01:57] <axw> yup
[01:57] <thumper> awesome!
[01:58] <thumper> axw: let me poke around in the code and see if I can get this working nicely...
[01:59] <thumper> axw: I think perhaps we should default to use the system key for 'juju ssh'
[01:59] <thumper> axw: that would make the windows code work nicer
[01:59] <thumper> axw: you are doing the ssh util work for windows yes?
[02:01] <axw> thumper: I'm not so sure we should be passing that key around in the .jenv though, should we?
[02:01] <axw> that would make it difficult to revoke access
[02:01] <thumper> axw: oh, interesting point
[02:01] <axw> thumper: I will be working on making it work for windows, yes
[02:02] <thumper> hmm...
[02:02] <thumper> axw: so, what are your thoughts on that?
[02:03] <thumper> we want a system identity
[02:03] <thumper> and if we can use the same that we have for mongo, then that should be fine
[02:03] <thumper> but we still need something to watch bootstrap with
[02:03] <thumper> perhaps that is a different id?
[02:03] <axw> thumper: sure, I just don't think we should carry it around outside the system; ideally we should dispose of it after bootstrap
[02:04] <axw> from the client I mean
[02:04] <thumper> we want something that will work out of the box with windows users
[02:04] <thumper> axw: but I think we should create a default user key...
[02:04] <thumper> or...
[02:05] <thumper> perhaps we just create the default user key if there is no local one found
[02:05] <thumper> and that is a separate issue
[02:05] <thumper> from the bootstrap issue
[02:05] <axw> thumper: yeah I see your point. I guess we do want another one
[02:05] <axw> we want the system one to be different to the default one used by the CLI
[02:05] <thumper> ok, my branch will work to make this system identiy
[02:05] <thumper> work
[02:05] <axw> because of revocation
[02:06] <axw> sounds good
[02:06] <thumper> axw: yes agree to that last statement
[02:07] <axw> thumper: I think bootstrap can just create another key if it doesn't have one
[02:07] <axw> for the CLI
[02:07]  * thumper nods
[02:07] <thumper> axw: that is a separate bit of work though
[02:07] <axw> thumper: yes, I can do that later
[02:07] <thumper> lets go with the system identity, and using that for the bootstrap
[02:07] <thumper> ...
[02:15] <axw> thumper: what about CLI users other than the bootstrapper?
[02:16] <thumper> not sure yet
[02:16] <thumper> I'm actually trying to find the code where it loads the authorized keys
[02:16] <thumper> the code I'm reading seems to indicate that it doesn't bother
[02:16] <thumper> unless I set them explicitly
[02:16] <thumper> but I know this is wrong...
[02:18] <thumper> ugh
[02:18] <thumper> an OR
[02:19] <axw> thumper: maybe just updated environs.BootstrapContext to add the key to whatever's computed?
[02:30] <thumper> axw: is the ca-private-key the thing we use to talk to mongo?
[02:30] <thumper> axw: if so, that is in the .jenv file in the bootstrap config
[02:30] <thumper> so perhaps we do want a different identity?
[02:30] <thumper> something that gets generated and written to cloud init, but not on the client side
[02:30] <axw> thumper: it is in there, but I think fwereade wants it out
[02:31] <axw> thumper: and yes that's what we use for mongo
[02:31] <thumper> ah, fair call
[02:31]  * thumper goes to make coffee
[02:31] <thumper> this takes more thinking than I thought :)
[02:31] <thumper> the identity stuff that is
[02:31] <thumper> not the making coffee
[02:31] <axw> hehe
[02:32] <axw> not enough coffee makes making coffee more difficult
[03:39]  * axw -> lunch
[03:48] <hazmat> wrt to put charm api, it appears to be unconditionally setting the scheme to local, deploy cli landing should resolve
[04:28] <thumper> axw: are you good with me updating our go.crypto to tip?
[04:29] <thumper> also, how do I find the full hash of an hg tip revision?
[04:51] <thumper> axw: in the end, I have gone with a ssh.GenerateKey function
[04:51] <thumper> axw: I'm going to poke things tomorrow and test
[04:51] <thumper> but for today, I'm done
[04:51] <thumper> night all
[07:33] <axw> jam: I *think* the streams.canonical.com URL it's going to is correct, but what's there at the moment is in the wrong place
[07:34] <jam> axw: that's sort of what I expect as well, and we don't really want to be using it anyway
[07:34] <axw> that's the impression I got from wallyworld
[07:34] <jam> the bigger question is what else did we try (and fail) and why
[07:34] <axw> yep
[07:34] <jam> and they don't want to use --debug because of security purposes, but that's where we dump all the URLs we try
[07:35] <axw> It'd be good to see that in "verbose output" (that never got landed did it?)
[07:35] <axw> thumper's stuff
[07:36] <jam> verbose was never intended to dump step-by-step stuff,(I think) I think it was meant to stay in --debug, we just dump other useful but-maybe-dangerous stuff there.
[07:36] <axw> when I'm bootstrapping without --debug, it can sit there doing image/tools stuff for a fair while without any feedback
[07:36] <jam> --verbose is more about user info about what we're doing
[07:37] <axw> yeah I suppose that is a bit too much info for general consumption
[07:38] <jam> I think we also have a bug that we don't write the debug information for the one that actually worked :)
[07:39] <axw> heh
[07:40] <rogpeppe1> mornin' all
[07:40] <axw> hey rogpeppe1
[07:41] <rogpeppe1> axw: sorry i didn't manage to do your review yesterday - am looking at it now
[07:41] <axw> rogpeppe1: nps, thanks. actually it gave me time to make it a bit nicer :)
[07:41] <rogpeppe1> axw: my first thought when i looked at it was that it could probably be factored out into a separate little type
[08:06] <dimitern> rogpeppe1, jam, https://codereview.appspot.com/38540044/ if you can please
[08:12] <rogpeppe1> dimitern: will do
[08:12] <dimitern> ta!
[08:17] <axw> rogpeppe1: do we need go.crypto pinned at the rev it's at?
[08:17] <axw> rogpeppe1: thumper's doing some SSH key stuff and was wondering if we can move to the tip
[08:18] <rogpeppe1> axw: not as far as i'm aware
[08:18] <rogpeppe1> axw: it would be good to try tip
[08:18] <axw> ok
[08:18] <rogpeppe1> axw: but it may not be possible
[08:18] <rogpeppe1> axw: it might have some go1.2 deps
[08:18] <axw> yeah ok, will have to check that
[08:18] <axw> thanks
[08:18] <jam> axw: so... do you know why we need a juju-run process to be running if we are just ssh'ing into each machine anyway?
[08:19] <axw> jam: I was under the impression it was not long running
[08:19]  * axw re-reads thumper's email
[08:19] <jam> axw: tim's statement was that it couldn't be the existing code because the existing stuff wasn't long lived
[08:19] <jam> at least, I thought I remembered seeing that
[08:20] <axw> jam: are you referrng to this statement? `"juju run" is really syntactic sugar around "juju ssh" and the server
[08:20] <axw> component "juju-run" that does the execution inside a hook context.`
[08:21] <jam> axw: so I know Tim has a Runner object that sits on a port and lets hooks fire queries into it (the way the current one does, but apparently somehow different)
[08:22] <jam> it might be that we "juju ssh" into each machine, fire up that juju-run process, and then have it (or something else) spawn of clients that run the script you wrote.
[08:22] <jam> I'm not sure how it actually all ties together.
[08:22] <jam> it sounded ilke you ssh in to poke the juju-run process
[08:22] <jam> but it might be that you are doing "juju ssh juju-run myscript.bash"
[08:22] <jam> well
[08:23] <jam> for i in ???; do juju ssh $i juju ssh /usr/bin/juju-run myscript.bash; done
[08:23] <rogpeppe1> jam: are there some design docs for juju-run somewhere?
[08:23] <axw> jam: sorry, I haven't actually looked at the code yet - not entirely sure. that's not how I thought it worked. what I thought was that you ssh'd in, then ran "juju-run <hook> <command>", and <command> was executed within the hook context
[08:24]  * axw looks at code
[08:25] <axw> jam: so, I have only taken a very brief look, but it looks to me that the runner/socket is just for that process
[08:25] <axw> it's just reusing the existing jujuc code
[08:26] <axw> hrm, or maybe not
[08:29] <jam> axw: related code, but definitely a different object
[08:30] <jam> can anyone look at: https://codereview.appspot.com/40670043/ its been sitting for a week now
[08:31] <axw> jam: I see; in that case, I'm not sure why SSH is required here.
[08:31] <axw> there's still the machine case, but that's a bit different anyway
[08:31] <axw> jam: I'll take a look
[08:34] <axw> jam: re the juju-run stuff: how else would you do it? you'd need to put something in state, right? and then record the results there?
[08:42] <dimitern> rogpeppe1, is it good to land?
[08:42] <rogpeppe1> dimitern: sorry, still reviewing axw's
[08:43] <dimitern> rogpeppe1, ok
[08:53] <jam> axw: so it depends what you want as a result. If you're meant to just trigger a script to run, yes. If you're meant to end up in an interactive session on the remote machine, then you'd have to ssh
[08:54] <jam> axw: an open question, is this intended to run sequentially on all machines, or would all machines fire up at the same time
[08:54] <jam> if parallel, then interactive session (or even printing to the screen) is pretty useless
[08:54] <jam> if sequential, then this really scales poorly when you have 100s of machines
[08:55] <axw> jam: my understanding is it's meant to be parallel and non-interactive, but I'm not 100% sure
[08:55] <axw> fwereade: hah, good point about the nonces
[08:56] <axw> fwereade: yes, pretty certain it was always "manual:..."
[08:56] <axw> I will double check before basing anything on that tho
[08:56] <fwereade> axw, cool, thanks
[08:56] <fwereade> axw, I'm just on destroy-environment at last, sorry delay
[08:57] <axw> fwereade: cool
[08:58] <jam> axw: if non-interactive, then it seems like you *don't* want to ssh into each one. (you don't really want to fire off 100 ssh connections all at once, either)
[09:00] <jam> btw, hi fwereade
[09:00] <fwereade> jam, heyhey
[09:01] <rogpeppe1> axw: you have a review
[09:01] <axw> rogpeppe1: thanks
[09:02] <fwereade> jam, axw: `juju run` is non-interactive, there's juju ssh for direct interactivity
[09:02] <axw> right
[09:03] <fwereade> jam, axw: the actual degree of parallelism required has not been specified, but a number of ideas have been floated around the concept
[09:03] <jam> fwereade: so some review questions... Do we want to have 'remove-machine' in a 1.16 branch? It has been approved, but it is more of a do-we-want-this-policy
[09:04] <fwereade> jam, axw: round-robin has been mentioned; parallel has been mentioned; parallel with horrid hacked-on interactivity has ever come up
[09:05] <fwereade> jam, what do we gain from a new 1.16 with that in?
[09:05] <jam> fwereade: or it could be driven from the db without ssh at all?
[09:05] <jam> fwereade: compatibility, especially with docs
[09:05] <jam> though you still have "you must have newer than X"
[09:06] <jam> but it would make "remove-machine" available in a stable release
[09:07] <axw> jam: the only thing I see being an issue with going through the db is that there's no ephemeral node support to handle the edge cases around client termination
[09:07] <axw> jam: it's not interactive, but there's still a session to maintain
[09:09] <axw> rogpeppe1: "This should probably allow itself to be stopped when closed.j"  -- do you mean use an additional select with a time.After?
[09:09] <rogpeppe1> axw: yeah
[09:09] <axw> thanks
[09:10] <jam> axw: I don't quite see how it is different from how we fire hooks normally, it is just a custom script instead of a charm hook
[09:10] <rogpeppe1> dimitern: reviewed
[09:10] <dimitern> rogpeppe1, thank
[09:10] <dimitern> s
[09:10] <axw> jam: the main difference is that the result needs to live somewhere. who owns that?
[09:12] <fwereade> jam, sorry, I missed the context on remove-machine
[09:13] <fwereade> jam, did you have any thoughts re the more human vocabulary I handwaved around in that thread yesterday?
[09:13] <jam> axw: seems easy enough to put it into the DB as a result of running the request
[09:14] <fwereade> jam, axw: questions of how much we store and for how long become interesting
[09:14] <jam> fwereade: so, there was a discussion that we should use "remove-*" for stuff instead of "destroy-*" and it is easy to add those aliases into a 1.16 release. I have a fairly trivial patch up, just waiting on whether we *want* to do it. Its approved, but I wanted to run it by you.
[09:14] <fwereade> jam, so, indeed, I think I am now up to speed on it
[09:14] <jam> fwereade: as for your natural language stuff, I think you had interesting points, but part of that is what we can evolve into, and we can have a consistent lower level terminology
[09:15] <jam> fwereade: for juju-run, if you aggregate the results somewhere (like the DB) then you do need a way to see it (is the suggestion that normally it just prints to your console via ssh?) that still seems like a whole lot of spam unless you very carefully craft the script to give enough context so you can figure out which machine actually "failed"
[09:16] <jam> so either, there isn't much result, so it doesn't matter, or there is some result, but you'd really rather have that logged and aggregated
[09:16] <jam> you *can* do "juju run foo.sh >aggregate.this.txt"
[09:42] <rogpeppe1> jam, fwereade: is there a design doc for juju-run? i'd like to contribute to the discussion, but i don't actually know what the goals are.
[10:23] <axw> rogpeppe1: updated
[10:26] <rogpeppe1> axw: re: "shouldn't this use the mutex?"
[10:26] <rogpeppe1> axw: it looks to me as if inst.InstanceId is inside the embedded ec2.Instance
[10:26] <rogpeppe1> axw: and hence should be protected by the same mutex
[10:26] <axw> rogpeppe1: gah, so it is
[10:27] <axw> rogpeppe1: sorry, will fix it now
[10:27] <rogpeppe1> axw: thanks
[10:29] <jam> rogpeppe1: I don't know of one, but tim is the one driving it
[10:38] <axw> rogpeppe1: updated again, sorry about that
[10:38] <rogpeppe1> axw: np
[10:41] <axw> bbl
[10:45] <jam> rogpeppe1: axw, mgz_: standup
[10:45] <jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[12:38] <jam> fwereade: poke about where to put worker/provisioner/authentication.go
[12:41] <fwereade> jam, how do you feel about environs?
[12:42] <jam> fwereade: so "NewAPIAuthenticator" doesn't feel like it should be in environs
[12:42] <jam> and NewEnvironAuthenticator feels ok there
[12:43] <jam> the issue is that they both want to share the actual underlying implementation
[12:43] <fwereade> jam, well, it's about giving access to a <handwave> environ
[12:43] <jam> which just has a way to get a StateInfo and then populate it with its final machine password stuff
[12:43] <fwereade> jam, I'm at least halfway inclined to just give it its own package somewhere
[12:44] <fwereade> jam, the only thing I'm sure of is that it's not exclusive to worker/provisioner, but it is something to do with setting up instances
[12:44] <jam> fwereade: arguably the simpleAuth code should be exposed in state/ and the others lay on top of that?
[12:44] <fwereade> jam, state doesn't seem very correct, in every case but bootstrap I think it's api-ey really
[12:47] <jam> well, the api server uses it internally
[12:47] <jam> which is why NewEnviron* is still necessary
[12:57] <fwereade> natefinch, https://codereview.appspot.com/36290043/patch/190001/200015 is going to collide with you, isn't it?
[13:05] <natefinch> fwereade, ish.  Shouldn't be a big deal.
[13:18] <mattyw> fwereade, jam I still can't reproduce the problem in https://code.launchpad.net/~mattyw/juju-core/add-owner-to-service/+merge/191192. I sometimes see Error: Test left sockets in a dirty state but no other errors (although that happens on trunk as well - has done for a while)
[13:19] <mattyw> ^^ any idea what might be going wrong?
[13:19] <jam> mattyw: we've had some issues with flaky tests, I just wanted to know if this was caused by your change. As it doesn't seem related, I'll just submit again.
[13:20] <jam> fwereade: when are we running mongo without ssl?
[13:20] <mattyw> jam, ok thanks - I'll keep an eye on it
[14:01] <natefinch> man, this USB ethernet adapter crashing my laptop is not cool (especially given there is no ethernet plug on the laptop).....
[14:02] <natefinch> anyway, I have to go snowblow my driveway, which will probably  take me a couple hours all told.
[14:03] <natefinch> jam, rogpeppe1: I verified that the test failure I'm having definitely is only happening with mongo 2.2, and not 2.4.  Not sure exactly why yet, but now that I can A/B test easily, I should be able to figure it out.
[14:06] <fwereade> jam, sorry I missed you -- it's for the store... but I am suddenly suspicious of the Right Thing to do there
[14:06] <fwereade> jam, I think it's probably better to factor out the existing store test harness and use that
[14:07] <fwereade> jam, than to introduce a fresh entanglement between the two
[14:20] <rogpeppe1> wow, my internet is super flaky today
[14:20] <rogpeppe1> can anyone see this?
[14:28] <mattyw> rogpeppe1, I can
[14:29] <rogpeppe1> mattyw: ok, that's something at least :-)
[14:29] <mattyw> rogpeppe1, also - I'm getting a "x509: certificate is valid for *" error when trying to connect to the core api on 17070 (it seems to happend in my call to websocket.Dial)
[14:30] <mattyw> is there a particular version of websocket I should be using do you think?
[14:30] <rogpeppe1> mattyw: could you paste the code that you're using to dial?
[14:30] <rogpeppe1> mattyw: in general, you should be using the state/api package to connect to the API
[14:30] <rogpeppe1> mattyw: (assuming you're using Go)
[14:31] <mattyw> rogpeppe1, I am, I was just kinda messing around with connecting to the websocket in go
[14:32] <rogpeppe1> mattyw: you can connect if you use InsecureSkipVerify
[14:32] <mattyw> rogpeppe1, 	ws, err := websocket.Dial("wss:/adr:17070", "", "http://localhost")
[14:33] <mattyw> ah, I'm not doing any tls at all
[14:33] <rogpeppe1> mattyw: otherwise your client won't know about the root CA cert that's used for the server
[14:33] <rogpeppe1> mattyw: you *are* doing tls
[14:33] <rogpeppe1> mattyw: that's the "wss:" thing
[14:33] <mattyw> rogpeppe1, but I'm not setting up any tls config
[14:34] <rogpeppe1> mattyw: ah yes.
[14:34] <mattyw> (which is what I meant in my head at least :))
[14:34] <rogpeppe1> mattyw: look at how it's done in state/api/apiclient.go:/Open
[14:34] <mattyw> rogpeppe1, will do, thanks again
[14:35] <axw> rogpeppe1: https://codereview.appspot.com/43650045 exercises the Addresses/Refresh code in provider/ec2
[14:35] <rogpeppe1> axw: looking
[14:35] <axw> rogpeppe1: I updated provider/ec2 again, there was a bug
[14:35] <mattyw> rogpeppe1, thanks for the acme-friendly shortcut ;)
[14:36] <rogpeppe1> mattyw: are you using acme now?
[14:38] <rogpeppe1> axw: what was the bug?
[14:40] <axw> rogpeppe1: Addresses was holding the lock around refresh(), which called inst.Id() and took the lock
[14:40] <axw> well, tried to
[14:41] <axw> so, deadlock
[14:41] <rogpeppe1> axw: ah, good thing i suggested the test then :-)
[14:41] <axw> very
[14:43] <rogpeppe1> axw: i still think we should use AddScripts rather than AddFile - someone might change AddFile to use the cloudinit write_files feature, which would then potentially break the nonce.txt logic
[14:43] <axw> rogpeppe1: fair point
[14:43] <axw> ok, I'll change it
[14:43] <rogpeppe1> axw: thanks
[14:43]  * rogpeppe1 goes for lunch
[14:55] <jamespage> hazmat, re mongodb build without scripting - which scons option are you referring to?  I can toggle between v8 and spidermonkey in our current source package (2.4.8) but I can't figure out how to disable it completely
[14:55] <axw> rogpeppe1: can you please approve the ec2test MP when you're back? I'm not in the group
[14:56] <hazmat> jamespage, usev8
[14:56] <axw> rogpeppe1: and/or merge it if there's no bot
[14:56] <hazmat> jamespage, https://github.com/mongodb/mongo/blob/master/SConstruct#L452
[14:57] <hazmat> jamespage, it comes up a few times.. agreed its not clear if its  toggle for spidermonkey or disable
[14:57] <jamespage> hazmat, it certainly was
[14:57] <jamespage> but upstream don't ship spidermonkey any longer
[14:57] <jamespage> "--usesm"
[14:59] <hazmat> jamespage, so reaching out to upstream sounds like the thing to do.. i don't see the usesm option in trunk scons.
[14:59] <hazmat> either that or trying a build without the v8 option
[14:59] <jamespage> hazmat, no its gone
[14:59] <jamespage> hazmat, if you don't specify it default to v8
[14:59] <jamespage> I'll poke at it a bit
[14:59]  * hazmat fires up a build on a spare server
[15:30] <dimitern> jam, rogpeppe1, https://codereview.appspot.com/43860043 AddCharm via the API
[15:35] <axw> fwereade: the nonce for manual bootstrap nodes does not start with "manual:". do you think it's still okay to use it, documenting that?
[15:36] <rogpeppe1> niemeyer: does this look reasonable to you? https://codereview.appspot.com/43650045/
[15:37] <axw> fwereade: that case *could* be detected by checking that id == "0" && extracting the provider type from EnvironConfig, but that's pretty heavy handed
[15:37] <fwereade> axw, hmm, possibly, I don't suppose that one has any useful distinguishing features?
[15:37] <axw> fwereade: not that I've thought of so far
[15:37] <niemeyer> rogpeppe1: What happens in practice?
[15:37] <niemeyer> rogpeppe1: I mean, what is the real EC2 doing about this?
[15:37] <rogpeppe1> niemeyer: the DNS name appears some time after the instance has been started
[15:38] <axw> fwereade: its instance-id is "manual:", but we've established that's not good enough to rely on
[15:38] <rogpeppe1> niemeyer: so any realistic client will need to poll it
[15:38] <niemeyer> rogpeppe1: Sounds good then
[15:38] <rogpeppe1> niemeyer: cool, thanks
[15:38] <niemeyer> rogpeppe1: np, thanks for asking
[15:39] <rogpeppe1> axw: will submit now
[15:39] <fwereade> axw, you know, I'm not so bothered by the weight as I am by the correctness
[15:39] <fwereade> axw, it's not a cost we'll be paying often enough to worry about, I think
[15:39] <axw> rogpeppe1: thanks
[15:40] <axw> fwereade: true
[15:40] <axw> fwereade: in fact, I won't even be passing it in in my case, because I don't check manager machines
[15:40] <fwereade> axw, thought that might be the case
[15:41] <axw> fwereade: so, now might be a good time to change the provider name from "null" to "manual"
[15:41] <fwereade> axw, please still test that behaviour in case we do ever end up with demoted machine 0s ;)
[15:41] <axw> certainly
[15:41] <fwereade> axw, most certainly, but I suspect that may take some finessing around upgrades
[15:42] <fwereade> axw, *maybe* you could get away with registering the same provider twice under different names..?
[15:43] <axw> hmm maybe, will have to see. I can make this code check for either "null" or "manual" for now
[15:47] <rogpeppe1> axw: FYI i just got this error when bootstrapping:
[15:47] <rogpeppe1> Connection to ec2-54-196-224-38.compute-1.amazonaws.com closed.
[15:47] <rogpeppe1> error: cannot open state: cannot create log collection: unauthorized mongo access: unauthorized
[15:47] <rogpeppe1> axw: i haven't looked into it but i suspect something is trying to talk to mongo before it's ready
[15:49] <axw> rogpeppe1: hmm, there's no changes regarding mongo communications in synchronous bootstrap
[15:50] <axw> rogpeppe1: are you on trunk?
[15:50] <rogpeppe1> axw: yeah
[15:51] <axw> rogpeppe1: with my just-merged branch?
[15:51] <axw> I'll test it again
[15:51] <rogpeppe1> axw: hmm, not sure
[15:51] <axw> rogpeppe1: shouldn't actually matter, just curious
[15:51] <rogpeppe1> axw: it's the kind of thing that wouldn't happen very often, if it's what i suspect
[15:52] <rogpeppe1> axw: i'll see if it happens again
[15:53] <rogpeppe1> axw: your goamz branch is now merged
[15:53] <axw> rogpeppe1: great, thanks
[15:54] <axw> rogpeppe1: ah, I should've updated dependencies.tsv... will do that now
[15:54] <rogpeppe1> axw: good point
[15:54] <rogpeppe1> axw: revno 44
[15:54] <axw> thanks
[15:56] <rogpeppe1> axw: ah, it's not bootstrap's fault at all
[15:56] <rogpeppe1> axw: i just wasn't printing enough log messages
[15:57] <axw> rogpeppe1: thanks for checking
[15:59]  * rogpeppe1 reboots
[16:10] <axw> night all
[16:14] <dimitern> natefinch, ping
[16:14] <dimitern> natefinch, can you take a look at this please? since roger is not around. https://codereview.appspot.com/43860043
[16:22] <natefinch> dimitern, sure
[16:47] <mattyw> fwereade, I guess we should have a chat about the next stage of the juju id stuff
[17:14] <natefinch> dimitern, can we put Info in the charm.Repository interface? I'd much prefer that than doing some casting to anonymous interfaces to access that method.
[17:19] <dimitern> natefinch, actually, I wasn't sure about using Info() or maybe just lazy not to calculate the sha256 from the already downloaded file
[17:20] <dimitern> natefinch, i'll change that to use only Get and read and calculate the hash from the downloaded charm
[17:21] <natefinch> that also works
[18:36] <rogpeppe> dimitern: you've got a review
[18:36] <rogpeppe> natefinch, dimitern: i made an alternative suggestion
[18:36] <rogpeppe> natefinch, dimitern: which hopefully works out a bit simpler than calculating the hash yourself
[19:01]  * rogpeppe is done for the day
[19:04] <rogpeppe> darn juju-restore is destroying its own re-bootstrapped machine
[19:04] <rogpeppe> g'night all
[19:29] <natefinch> thumper, morning
[19:29] <thumper> o/ natefinch
[19:29]  * thumper trawls through the overnight emails
[20:26] <natefinch> thumper, how's your knowledge of mongo?
[20:27] <thumper> natefinch: virtually non-existent
[20:27] <natefinch> thumper, heh.  My HA tests are failing on 2.2 but passing on 2.4.... and I can't figure out why.
[20:40] <thumper> hmm... trying to bootstrap ec2 failed with an error around simple streams
[20:40] <thumper> WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju
[20:40] <thumper> ERROR bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9: element <hr> closed by </body>
[20:56] <natefinch> thumper sounds like you might be getting a 404 not found page instead of the XML you're supposed to get, and it's trying to parse the page's HTML
[20:56] <thumper> natefinch: that's what I thought too
[20:56] <thumper> but since I actually needed to upload tools
[20:56] <thumper> it was a convenient error
[20:57] <natefinch> heh
[20:57] <natefinch> thumper, it does worry me that we're not checking the http error code before trying to parse what's returned, though
[20:58] <thumper> heh
[20:58] <thumper> yeah
[20:59] <thumper> should file a bug
[20:59] <thumper> I'm now confused...
[20:59] <thumper> with my work
[21:01] <thumper> WTF!
[21:01] <thumper> natefinch: hangout?
[21:01] <thumper> it might help if I talk this through
[21:03] <natefinch> sure... one sec
[21:05] <thumper> natefinch: I worked it out :)
[21:05] <natefinch> thumper, ha, ok, cool
[21:05] <thumper> dumb permissions...
[21:06] <natefinch> thumper, heh, something like that happened when I was building mongo from source yesterday.  30 minute build, fails at the very end with a permissions issue.
[21:06] <thumper> I have code that now creates a juju system ssh identity file and adds to the authorized keys
[21:06] <thumper> and it works for ec2 and local
[21:07] <thumper> so probably everything
[21:07] <thumper> although care should be taken with manual
[22:42] <thumper> wallyworld_: o/
[22:43] <wallyworld_> heloooo
[22:43] <thumper> wallyworld_: good break?
[22:43] <wallyworld_> so many emails
[22:43] <thumper> :)
[22:43] <wallyworld_> yeah, no internet
[22:43] <wallyworld_> great result in the cricket :-D
[22:43] <thumper> wallyworld_: I'm heading off to the gym shortly, but we have a scheduled call in just over 2 hours
[22:43] <wallyworld_> yep
[22:43] <thumper> so we can chat then
[22:43] <wallyworld_> ok