| thumper | axw: hey there | 00:48 |
|---|---|---|
| thumper | axw: sinzui_ is having issues with your hp fix branch, seems to have a bad import | 00:49 |
| axw | thumper: reading the email now | 00:52 |
| axw | eh wtf | 00:53 |
| axw | aw crap, I think I enabled goimports and it mucked about with the imports | 00:54 |
| 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:55 |
| * axw feels vindicated | 00:56 | |
| axw | ;) | 00:56 |
| thumper | davecheney: I don't suppose your ssh go stuff has keygen? | 00:56 |
| axw | thumper: AFAIK they | 00:59 |
| axw | are just PEM keys | 00:59 |
| thumper | axw: I'm not entirely sure what that means | 01:00 |
| 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:01 |
| 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:02 |
| davecheney | thumper: it wouldn't be hard to write | 01:03 |
| 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:04 |
| 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:05 |
| davecheney | yup | 01:06 |
| davecheney | lemmie look in the ssh package tests | 01:06 |
| davecheney | we probably have some code | 01:06 |
| thumper | davecheney: awesome sauce | 01:07 |
| * thumper channels fwereade | 01:07 | |
| 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:31 |
| davecheney | thumper: yup | 01:36 |
| davecheney | looking after lunch | 01:36 |
| thumper | ok | 01:43 |
| thumper | ta | 01:43 |
| 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:47 |
| axw | thumper: https://gist.github.com/axw/8016123 | 01:55 |
| thumper | axw: what about the identity file that you can hand off to ssh? | 01:56 |
| 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:57 |
| thumper | axw: let me poke around in the code and see if I can get this working nicely... | 01:58 |
| 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? | 01:59 |
| 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:01 |
| thumper | hmm... | 02:02 |
| thumper | axw: so, what are your thoughts on that? | 02:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| axw | sounds good | 02:06 |
| thumper | axw: yes agree to that last statement | 02:06 |
| 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:07 |
| axw | thumper: what about CLI users other than the bootstrapper? | 02:15 |
| 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:16 |
| thumper | ugh | 02:18 |
| thumper | an OR | 02:18 |
| axw | thumper: maybe just updated environs.BootstrapContext to add the key to whatever's computed? | 02:19 |
| 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:30 |
| 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:31 |
| axw | not enough coffee makes making coffee more difficult | 02:32 |
| * axw -> lunch | 03:39 | |
| hazmat | wrt to put charm api, it appears to be unconditionally setting the scheme to local, deploy cli landing should resolve | 03:48 |
| thumper | axw: are you good with me updating our go.crypto to tip? | 04:28 |
| thumper | also, how do I find the full hash of an hg tip revision? | 04:29 |
| 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 | 04:51 |
| === axw_ is now known as axw | ||
| 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:33 |
| 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:34 |
| axw | It'd be good to see that in "verbose output" (that never got landed did it?) | 07:35 |
| axw | thumper's stuff | 07:35 |
| 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:36 |
| axw | yeah I suppose that is a bit too much info for general consumption | 07:37 |
| jam | I think we also have a bug that we don't write the debug information for the one that actually worked :) | 07:38 |
| axw | heh | 07:39 |
| rogpeppe1 | mornin' all | 07:40 |
| axw | hey rogpeppe1 | 07:40 |
| 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 | 07:41 |
| dimitern | rogpeppe1, jam, https://codereview.appspot.com/38540044/ if you can please | 08:06 |
| rogpeppe1 | dimitern: will do | 08:12 |
| dimitern | ta! | 08:12 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| * axw looks at code | 08:24 | |
| 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:25 |
| axw | hrm, or maybe not | 08:26 |
| jam | axw: related code, but definitely a different object | 08:29 |
| jam | can anyone look at: https://codereview.appspot.com/40670043/ its been sitting for a week now | 08:30 |
| 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:31 |
| 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:34 |
| dimitern | rogpeppe1, is it good to land? | 08:42 |
| rogpeppe1 | dimitern: sorry, still reviewing axw's | 08:42 |
| dimitern | rogpeppe1, ok | 08:43 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| axw | fwereade: cool | 08:57 |
| 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) | 08:58 |
| jam | btw, hi fwereade | 09:00 |
| fwereade | jam, heyhey | 09:00 |
| rogpeppe1 | axw: you have a review | 09:01 |
| axw | rogpeppe1: thanks | 09:01 |
| fwereade | jam, axw: `juju run` is non-interactive, there's juju ssh for direct interactivity | 09:02 |
| axw | right | 09:02 |
| 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:03 |
| fwereade | jam, axw: round-robin has been mentioned; parallel has been mentioned; parallel with horrid hacked-on interactivity has ever come up | 09:04 |
| 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:05 |
| jam | but it would make "remove-machine" available in a stable release | 09:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| fwereade | jam, sorry, I missed the context on remove-machine | 09:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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. | 09:42 |
| axw | rogpeppe1: updated | 10:23 |
| 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:26 |
| axw | rogpeppe1: sorry, will fix it now | 10:27 |
| rogpeppe1 | axw: thanks | 10:27 |
| jam | rogpeppe1: I don't know of one, but tim is the one driving it | 10:29 |
| axw | rogpeppe1: updated again, sorry about that | 10:38 |
| rogpeppe1 | axw: np | 10:38 |
| axw | bbl | 10:41 |
| jam | rogpeppe1: axw, mgz_: standup | 10:45 |
| jam | https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig | 10:45 |
| jam | fwereade: poke about where to put worker/provisioner/authentication.go | 12:38 |
| fwereade | jam, how do you feel about environs? | 12:41 |
| jam | fwereade: so "NewAPIAuthenticator" doesn't feel like it should be in environs | 12:42 |
| jam | and NewEnvironAuthenticator feels ok there | 12:42 |
| 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:43 |
| 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:44 |
| jam | well, the api server uses it internally | 12:47 |
| jam | which is why NewEnviron* is still necessary | 12:47 |
| fwereade | natefinch, https://codereview.appspot.com/36290043/patch/190001/200015 is going to collide with you, isn't it? | 12:57 |
| natefinch | fwereade, ish. Shouldn't be a big deal. | 13:05 |
| === gary_poster|away is now known as gary_poster | ||
| 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:18 |
| 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:19 |
| jam | fwereade: when are we running mongo without ssl? | 13:20 |
| mattyw | jam, ok thanks - I'll keep an eye on it | 13:20 |
| natefinch | man, this USB ethernet adapter crashing my laptop is not cool (especially given there is no ethernet plug on the laptop)..... | 14:01 |
| natefinch | anyway, I have to go snowblow my driveway, which will probably take me a couple hours all told. | 14:02 |
| 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:03 |
| === natefinch is now known as n8f-snowblow | ||
| 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:06 |
| fwereade | jam, than to introduce a fresh entanglement between the two | 14:07 |
| rogpeppe1 | wow, my internet is super flaky today | 14:20 |
| rogpeppe1 | can anyone see this? | 14:20 |
| mattyw | rogpeppe1, I can | 14:28 |
| 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:29 |
| 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:30 |
| mattyw | rogpeppe1, I am, I was just kinda messing around with connecting to the websocket in go | 14:31 |
| rogpeppe1 | mattyw: you can connect if you use InsecureSkipVerify | 14:32 |
| mattyw | rogpeppe1, ws, err := websocket.Dial("wss:/adr:17070", "", "http://localhost") | 14:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| rogpeppe1 | mattyw: are you using acme now? | 14:36 |
| rogpeppe1 | axw: what was the bug? | 14:38 |
| axw | rogpeppe1: Addresses was holding the lock around refresh(), which called inst.Id() and took the lock | 14:40 |
| axw | well, tried to | 14:40 |
| axw | so, deadlock | 14:41 |
| rogpeppe1 | axw: ah, good thing i suggested the test then :-) | 14:41 |
| axw | very | 14:41 |
| 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:43 | |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 14:59 | |
| dimitern | jam, rogpeppe1, https://codereview.appspot.com/43860043 AddCharm via the API | 15:30 |
| 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:35 |
| rogpeppe1 | niemeyer: does this look reasonable to you? https://codereview.appspot.com/43650045/ | 15:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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 |
| === mgz_ is now known as mgz | ||
| fwereade | axw, thought that might be the case | 15:40 |
| 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:41 |
| fwereade | axw, *maybe* you could get away with registering the same provider twice under different names..? | 15:42 |
| axw | hmm maybe, will have to see. I can make this code check for either "null" or "manual" for now | 15:43 |
| 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:47 |
| axw | rogpeppe1: hmm, there's no changes regarding mongo communications in synchronous bootstrap | 15:49 |
| axw | rogpeppe1: are you on trunk? | 15:50 |
| rogpeppe1 | axw: yeah | 15:50 |
| 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:51 |
| rogpeppe1 | axw: i'll see if it happens again | 15:52 |
| rogpeppe1 | axw: your goamz branch is now merged | 15:53 |
| axw | rogpeppe1: great, thanks | 15:53 |
| 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:54 |
| === n8f-snowblow is now known as natefinch | ||
| rogpeppe1 | axw: ah, it's not bootstrap's fault at all | 15:56 |
| rogpeppe1 | axw: i just wasn't printing enough log messages | 15:56 |
| axw | rogpeppe1: thanks for checking | 15:57 |
| * rogpeppe1 reboots | 15:59 | |
| axw | night all | 16:10 |
| 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:14 |
| natefinch | dimitern, sure | 16:22 |
| === BradCrittenden is now known as bac | ||
| mattyw | fwereade, I guess we should have a chat about the next stage of the juju id stuff | 16:47 |
| 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:14 |
| 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:19 |
| dimitern | natefinch, i'll change that to use only Get and read and calculate the hash from the downloaded charm | 17:20 |
| natefinch | that also works | 17:21 |
| === alexlist` is now known as alexlist | ||
| 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 | 18:36 |
| * rogpeppe is done for the day | 19:01 | |
| rogpeppe | darn juju-restore is destroying its own re-bootstrapped machine | 19:04 |
| rogpeppe | g'night all | 19:04 |
| natefinch | thumper, morning | 19:29 |
| thumper | o/ natefinch | 19:29 |
| * thumper trawls through the overnight emails | 19:29 | |
| natefinch | thumper, how's your knowledge of mongo? | 20:26 |
| 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:27 |
| 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:40 |
| 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:56 |
| 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:57 |
| thumper | heh | 20:58 |
| thumper | yeah | 20:58 |
| thumper | should file a bug | 20:59 |
| thumper | I'm now confused... | 20:59 |
| thumper | with my work | 20:59 |
| thumper | WTF! | 21:01 |
| thumper | natefinch: hangout? | 21:01 |
| thumper | it might help if I talk this through | 21:01 |
| natefinch | sure... one sec | 21:03 |
| thumper | natefinch: I worked it out :) | 21:05 |
| natefinch | thumper, ha, ok, cool | 21:05 |
| thumper | dumb permissions... | 21:05 |
| 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:06 |
| thumper | so probably everything | 21:07 |
| thumper | although care should be taken with manual | 21:07 |
| === hatch_ is now known as hatch | ||
| === gary_poster is now known as gary_poster|away | ||
| thumper | wallyworld_: o/ | 22:42 |
| 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 | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!