=== slank is now known as slank_away [05:38] wallyworld: /wave [05:39] g'day [05:42] jam: i've put up a couple of mp's - bootstrapping a real openstack works :-) [05:42] wallyworld: sounds great [05:42] but canonistack is responding now with a resource limit exceeded error, but it was working, o swear [05:43] i ran it against my user id for everything (public bucket etc), didn't try out shared tenant [06:06] wallyworld: you could certainly have started to many instances, etc in a time frame. [06:06] yes, i did a lot of debugging/testing [08:10] morning all! [08:12] rogpeppe: morning [08:12] rogpeppe, dimitern: morning [08:12] TheMue: hiya [08:14] i'd appreciate some comments on https://codereview.appspot.com/6878052 if anyone fancies having a look [08:15] Aaaargh, heavy rain showers here. OK, much warmer than a week ago, but so wet. [08:15] Thankfully no need to step out. [08:15] rogpeppe: *click* before continuing my OS X tests (build went w/o probs). [08:16] * dimitern looking as well [08:30] rogpeppe: done [08:30] dimitern: that was quick, thanks! [08:30] rogpeppe: np [08:43] wallyworld: ping [08:46] rogpeppe: I'm trying to use 'lbox propose' but I'm still getting "local error: protocol version not supported". [08:46] Is there any way to get more context in the error messages? [08:46] jam: lbox --verbose ? [08:48] rogpeppe: You've got a review. [08:49] TheMue: tyvm [08:49] rogpeppe: it looks like it might be a username failure, but where are the cached auth details saved? [08:49] rogpeppe: Missed to enter the LGTM, so after your answers I'll do it. ;) [08:49] jam: hmm, i've never looked, sorry [08:50] jam: i'd appreciate your comments on this CL too, if you have some time. https://codereview.appspot.com/6878052 [08:56] rogpeppe: ... it is telling me that it successfully read from a file that doesn't exist.... [08:56] jam: hmm. [08:56] jam: lbox is? [08:57] rogpeppe: I hacked rietveld to tell me where it was loading the credentials, and it logs "Successfully loaded from $HOME/.goetveld_codereview.appspot.com" but there is no such file. [08:57] jam: weird. more printfs required, i think :-) [08:58] jam: i could have a look, but i'd only be duplicating your work, and i can't reproduce the problem... [08:59] yeah, working on it [08:59] lots of prints now [09:01] rogpeppe: step 1: failed to read file, step 2: successfully read credentials... WTF? [09:01] lol [09:04] rogpeppe: there is a func "filterNotFound()" which turns not-found errors into nil [09:04] so it says it loaded when the credentials aren't actually there. [09:05] jam: so it's deliberate. perhaps this isn't the reason after all. [09:05] rogpeppe: sure, but the log message saying it successfully loaded credentials is confusing [09:05] And it isn't asking me to log in. [09:05] It did the very first time I ran it with -v [09:05] jam: indeed. and that seems odd. [09:05] and now it just dies [09:05] It seems to get a 401 [09:05] and then... protocol not supported tends to happen. [09:06] but I'm not able to get my creds into the system, because it doesn't get to the point of actually asking me to log in. [09:06] jam: if you run it with --debug, you'll see the traffic to and from the server too, which might help possibly [09:10] Hi rogpeppe (and thanks for all your helpful comments by the way!), hi jam. [09:10] h [09:10] hi jtv [09:11] jtv: hiya [09:11] jtv: on the go gotchas doc? [09:11] The Cultural Learnings For Make Benefit. [09:11] jtv: a great title [09:11] Julian's. Stroke of genius. [09:12] jtv: i think that at least some of it might be good to publish more widely [09:12] Good point. I'll mention it in our standup call. [09:12] Meanwhile, another thing you gents may be able to help with: [09:13] when a juju provider needs to know things like the base URL it should talk to get its virtual machines etc., that all goes into the config and is parsed out by Provider.SetConfig(), right? [09:13] jtv: yup [09:14] jtv: or at least it should be derivable from the config [09:14] Thanks. And in general, is the config meant to be a single level deep, or nest structures, or be very very deep so the whole world can fit in if needed..? [09:15] jtv: generally it's a single level [09:15] jtv: i'm not sure if we allow deeper nesting - it might be useful at some point (i've considered a situation where we might want nested provider configs...) [09:16] For gomaasapi we built a little object layer for dealing with dynamic JSON structures. Not great, but it gets us past the static/dynamic problem. [09:17] jtv: have you seen juju's schema package? [09:17] rogpeppe: well, eventually after running the command probably 50 times now, it finally asked for my password and I could get it entered. I still don't know what was wrong with the protocol, but it apparently blocked me actually logging in. [09:17] No..? [09:17] jtv: you can use a map[string]interface{} for dynamic structures, (I think) [09:18] jtv: it makes it easier to coerce dynamic JSON structures into a known form. [09:20] jam: yes we do use that, but our code hides the casting etc. underneath. [09:20] rogpeppe: that was part of our problem: we couldn't guarantee much about the known form. [09:21] jtv: how dynamic is the actual structure? We went with more of a known structs which allows the json marshall/unmarshall to handle casting to types rather than writing a lot of functions [09:21] (function calls) [09:21] jtv: that can be awkward [09:21] jtv: i'd be interested to see the range of forms you have to deal with. [09:21] (the argument is that if you don't actually know the structure, you don't really know how to use it, do you?) [09:22] Well in our case we had the problem of a boundary of responsibilities between the code that uses the objects (and thus has to know /something/ about their structure) and the code that serves them up. [09:22] jam: yeah, but json structures can be alarmingly content-dependent sometimes [09:23] jtv: you can pass in the expected structure (via interface{}) and have it get populated and returned [09:24] Yes. We had a few slightly different requirements though. The one thing we know is that "MAAS objects" are JSON objects with a resource_uri entry. [09:26] (Although conversely of course, a JSON object with a resource_uri entry need not be a MAAS object) [09:26] Was a bit shocked to find that numbers can parse to float64 *or* int, depending. [09:29] rogpeppe: should 'rpc' be in juju-core ? it feels like something that should be an external lib. [09:29] (with all the dep issues that entails, maybe not worth it yet, I guess) [09:29] jam: quite possibly. i think i'm in favour of leaving it in juju for the time being, as it may become more juju-specific. [09:30] jam: we can easily factor it out later (and i'm in favour of doing that when it stabilises) [09:31] TheMue: " [09:31] Just to get it right, the coverage of the API is defined by the types and their [09:31] methods here in the package, but those are using the generic way interact with [09:31] state? [09:31] " [09:31] TheMue: i'm not sure i understand your question there [09:33] rogpeppe: Just wanted to know if the type and methods the API exposed have to be defined in the API package like you've done it for Machine.InstanceId(). [09:34] TheMue: yes. that's how all our Go-implemented clients and agents will interact with the state [09:34] rogpeppe: Fine. [09:35] rogpeppe: So more control than exposing all public state types and methods. [09:35] TheMue: yes [09:35] rogpeppe: +1 [09:36] rogpeppe: Like it. [09:36] rogpeppe: Btw, our client runs fine on OS X. :D [09:36] TheMue: of course, external clients will speak JSON directly to the API server. [09:36] TheMue: cool. [09:37] TheMue: you ran the live tests? [09:37] rogpeppe: First step has been just to bootstrap. Next step are the live tests. [09:37] TheMue: ah, you bootstrapped ok - that's good enough for me :-) [09:38] rogpeppe: *lol* [09:38] TheMue: and juju status worked ok, presumably? [09:38] we may have a problem with openstack bootstrap, it seems the user_data we're passing is limited to 65K base64 encoded string [09:38] rogpeppe: Exactly [09:38] and ours is slightly over 80K [09:38] dimitern: compressed? [09:39] rogpeppe: no, it's just b64-ed [09:39] dimitern: that's huge, BTW. why is it so big? [09:39] rogpeppe: I don't know but I intend to find out shortly [09:39] dimitern: ec2 sends the user data compressed, BTW [09:39] dimitern: i mean the ec2 provider sends... [09:40] rogpeppe: nova does not support this, looking at the source [09:40] dimitern: the limit for ec2 user data is 16K and we fit in that alright. 80K is huge! [09:41] rogpeppe: it's either improperly encoded or it's repeated or something [09:42] dimitern: does nova need to know about the compression? i thought it was a cloud-init thing. [09:43] rogpeppe: not that I can see - compression is neither mentioned in the API/docs nor I can see it being handled at the nova source level [09:44] dimitern: https://help.ubuntu.com/community/CloudInit [09:44] dimitern: "content found to be gzip compressed will be uncompressed. The uncompressed data will then be used as if it were not compressed. " [09:45] rogpeppe: that's what I have http://paste.ubuntu.com/1589183/ [09:46] rogpeppe: I see - so nova doesn't have to handle the decompression - cloud init will do that itself? [09:46] dimitern: yeah [09:47] rogpeppe: so that paste looks not right? it should be gz-ed [09:48] rogpeppe: which module should I use? compress/zlib? [09:48] dimitern: check out the code in the ec2 provider [09:48] dimitern: zlib != gz, though they are similar [09:48] dimitern: there's already a convenience function to do it [09:48] (both are DEFLATE, but gz has different headers) [09:48] rogpeppe: can you point me where? [09:48] dimitern: (in trivial) [09:49] not to be confused with mgz, who has no headers :) [09:49] :D [09:49] dimitern: in the userData function in ec2.go [09:49] rogpeppe: ah, ok [09:49] dimitern: cdata := trivial.Gzip(data) [09:50] I have a head, though... [09:52] rogpeppe: yeah, this is removed in OS when porting the ec2 stuff .. weird [09:56] mgz: sometimes at least. :) [10:02] so, with the gzip part done, now it seems we need to set a public IP as well, otherwise you cannot connect to mongo, even with the sshebang VPN stuff for canonistack, and nova ssh machine-0 complains no public IPs are set [10:05] and I cannot ssh directly, because the authorized keys expect my key pair to be on chinstrap as well [10:20] and I cannot connect to the mongo on the bootstrap node at all - with either private canonistack IP or with an attached floating IP (public), even though I can see the secgroup allows port 37017 [10:21] should I be able? [10:24] dimitern: so is it trying to ssh to the machine, or is it trying to connect directly to mongo? [10:24] if it is a direct connect to mongo, then you would need an ssh tunnel to it, or as you mention we need a public ip set for the machine. [10:25] jam: directly on port 37017 [10:25] jam: I have a public IP set and through it it doesn't work (drops with conn refused, rather than blocking forever, when using a private IP) [10:27] jam: and I cannot seem to find a way to ssh into the machine to see what's running there (public key auth fails - used several ways to connect - with the sshebang, directly with -i ~/.ssh/mykey, etc.) [10:27] you can also just ssh to chinstrap, then use a 10. address from there to test things sometimes [10:27] it's likely the cloud-init was bugged though [10:27] mgz: tried that as well - still pubkey auth failed [10:27] dimitern: what you need to do is look at the boottime console output [10:28] mgz: how? juju bootstrap is doing all [10:28] which will tell you if injecting your public key failed somehow [10:28] dimitern: I'm pretty sure you can use a different ssh key to chinstrap than you use to the actual bootstrap node, but it might involve a bit of ssh config magic. [10:28] mgz: if I use lpsetup to launch a machine - it all works and at the end I'm in a ssh session [10:28] dimitern: eg by `euca-describe-instances` to get the i-000000 id form [10:29] then `euca-get-console-outp... something like that, don't remember the form [10:29] anyway, pipe that to file and pastebin it [10:29] novaclient should actually expose the console output stuff now as well [10:29] mgz: ahaa! 10x [10:30] mgz: nova list works for me [10:30] it reports the ip address of the target machine [10:30] mgz: http://paste.ubuntu.com/1589253/ [10:31] nova list works for me as well, but nova ssh says "no public address set", which is wrong - there is a fip set [10:31] jam: as in, what dimitern actually needs is the bootlog [10:31] the eucatools list was just to get the other id form to use with the console output command [10:31] dimitern: well, I don't use a public IP to ssh to [10:32] mgz: that's troublesome - 2013-01-30 09:54:04,352 - __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: 'H4sIAAAJbogA/+y9+ZOq2rIn...' [10:32] dimitern: ^right, that [10:33] dimitern: I use "nova list" which gives: in the last column "Networks" which has "canonistack:10.55.60.XX" and I just "ssh 10.55.60.XX" [10:33] I'm *so* glad I added that log line to cloud-init :) [10:33] mgz: yay :) [10:33] you appear to have done base64 then gzip? [10:33] it should be gzip then base64 [10:33] jam: using ssh 10.55.xx does not work either (pubkey auth error) [10:33] dimitern: um, I'm able to get to: 10.55.60.246 [10:34] mgz: thought just that :) I'm looking [10:34] which is the one listed in your log [10:34] once you ungzip, the first bit of literal text must be #cloud-config [10:34] jam: me too [10:34] sorry, bad paste [10:34] I get perm denied going to .246 [10:34] jam: exactly [10:34] jam: when cloud-init doesn't like the user data you pass (which includes the key to inject), you can't ssh to the machine in the normal way [10:35] jam: used to work before - in fact for things lpsetup created it works ok [10:35] mgz: sure, I imagine the key to use is in the cloud-init, and if that isn't there, bad news bears :) [10:36] mgz: any way to get gzip to decompress even when the data isn't complete? [10:36] it's there, but can't read the user-data dimitern passed, because it comes out base64ed still [10:36] jam: not really. [10:36] mgz: http://www.urbanophile.com/arenn/coding/gzrt/gzrt.html :) [10:37] but that might still be block-sized [10:37] well, it can be done, but cloud-init has no facilities to do it [10:37] and you can't get to the box to fiddle yourself [10:37] mgz: oh, I just want to see the decompression of the base64 stuff, to see if it makes any sense. [10:38] dimitern: btw, you might want to use pastebin.canonical.com for stuff that might contain things like private keys [10:38] p.u.c is fully public [10:39] cloud-init dump is generally safe, but yeah [10:39] jam: ah, ok, will do [10:40] jam: luckily, because of the bug no keys were actually of importance there [10:40] mgz: well, the 24 base-64 bytes is not enough to get any data out of gz [10:42] yeah, is a gzip stream though [10:42] mgz: well gzip("#cloud-config").encode('base64") => H8sIAAAA... which is the same as the paste bin. However I imagine that is the gzip header, and not the actual compressed contenct. [10:43] mgz: well, you can't take out arbitrary bytes in the middle, but if you get enough of the prefix, you should be able to get something out, I imagine. [10:43] H4s [10:44] well, we have the length [10:44] dimitern: one option is to dump the content (log it) in the client, to see what it thinks it is sending. And you can at least check that the prefix matches. [10:44] mgz: the error message sounds like it wants multipart sections [10:44] ah, not we don't [10:45] jam: I'm just checking with cloud-init, but I suspect over-endoing [10:45] mgz: but what dimitern posted before: http://paste.ubuntu.com/1589183/ [10:45] *encoding [10:45] jam, mgz: so I did bootstrap and logged, took the console log as well [10:45] mgz: I wonder if it was "base64(gzip(base64(content)))" or something like that [10:45] it seems the client is sending b64(gzip(cloud_init)) and it's exactly as it is - correctly [10:47] but yeah - I did the gzip(header) -> base64 and it's H4S.. something, so indeed another b64 is happening [10:47] dimitern: gzip("").encode('base64') == H4sIAAAA [10:47] so that is just the "I'm a gzip stream" bit [10:48] not the "and the content looks like #cloud-init" stuff. [10:50] it seems the data is not decoded on the other side [10:51] dimitern: so I'm wondering about the base64 nature [10:51] mgz: is there a reasonable way to get the cloud-init content out of pyjuju? [10:51] to compare? [10:52] yeah, but it's quite different [10:52] I don't think they even gzip it [10:52] where's the cloud-init decoding the stuff? [10:53] mgz: for ec2 rogpeppe said they gzip it, because the limit is 16K (in Os is 65K, ours uncompressed was 80K so bootstrap was failing with 500, and I added the gzip step as in ec2) [10:53] mgz: help.ubuntu.com indicates that we likely need to because of space limitations. [10:53] dimitern: I wonder if it could even be a "#cloud-config" with "\r\n" or some sort of line-ending/whitespace issue. [10:54] yeah, it's not gziped. [10:54] jam: the code to produce it is in userData() method in environ - cloudinit.Render() [10:55] append([]byte("#cloud-config\n"), data...) [10:55] so it's \n and whatever's there [10:55] so, wrapping it in mime junk would probably work, though it should function like this too, just trying to understand the handler code in cloud-init again [10:57] this... must be base64 over-encoding [10:57] mgz: well, "Content-Type: text/cloud-config" [10:57] what cloud-init is seeing is base64 encoded [10:57] https://help.ubuntu.com/community/CloudInit [10:57] mgz: exactly [10:57] generally, what you do is base64 to pass in json over the apu [10:57] doesn't say anything about base64 that I've found [10:58] mgz: what's in the cloudinit is yaml [10:58] then when you request the user-data from the metadata service, it's not base64 encoded [10:58] so, it's that stage, rather than anything gzip or cloud-config related [10:58] it never gets that far [10:58] dimitern: what's the branch with this code? [10:58] we're just base64ing too many times [10:59] mgz: cloud-init in juju-core - that's what I'm looking at [11:00] mgz: openstack api requires user_data to be base64 encoded [11:01] dimitern: goose also base64s [11:02] mgz: only goose does, juju-core doesn't touch the gzipped yaml [11:02] fwereade: https://codereview.appspot.com/6878052 :-) [11:02] rogpeppe, cheers ;) [11:04] wow, cloudinit.verifyConfig is the stupidest function I've seen in a while [11:05] mgz: but somehow the cloudinit doesn't expect base64-er userdata (with gzip inside) [11:05] it shouldn't come off the metadata service encoded [11:05] and doesn't [11:05] how is it taken from the metadata? [11:06] we could reproduce more closely what juju-core is doing, and in a safe way where ssh will still work, with lpsetup [11:06] dimitern: according to http://docs.openstack.org/trunk/openstack-compute/admin/content/user-data.html it is a web request [11:06] but I'm pretty sure it's not openstack at fault [11:06] mgz: is it possible to manually make a metadata request to verify what the instance got? [11:06] yeah, curl the magic url [11:06] but you need ssh to do that :) [11:06] mgz: what is the magic url? [11:06] openstack/date/user_data doesn't quite make sense [11:07] or is the 169.254 actually the magic IP? [11:07] it is. [11:07] mgz: cloudinit.verifyConfig pretty closely from the pyjuju code. [11:07] s/pretty/came pretty/ [11:08] mgz: so you have to do it from the instance? (it uses source address to determine what content to serve?) [11:08] yup. [11:08] mgz: booo [11:08] i'm starting a node now with lpsetup to see what the metadata can be [11:09] dimitern: interestingly, openstack's metadata is in yaml, but ec2's is in json [11:10] jam: yeah, because juju-core uses yaml for both [11:10] dimitern: *might* be a problem [11:10] dimitern: we can also hack around the ssh problem in juju-core [11:11] if you pass key_name=dimitern and have some keys installed [11:11] it won't matter if cloud-init gets borked data [11:11] mgz: keys installed where? [11:11] `nova keypair-list` [11:12] I'll double check the exact param as well [11:12] jam: i didn't think that ec2 used json at all [11:12] mgz: from what I can find, pyjuju does not gzip the content. [11:13] jam: indeed, I said that ^up there :) [11:13] rogpeppe: http://docs.openstack.org/trunk/openstack-compute/admin/content/metadata-service.html seems to indicate that if you get data from the metadata api in ec2 compat mode, it comes back as json [11:13] jam: we only need to gzip the content now because we're passing around big certificates and keys [11:13] ah, there is 'metadata' and 'metadata.json' perhaps [11:13] rogpeppe: sure, but for sanity checking, I might recommend dimitern not gzip until we get something working in case the decode step isn't working. [11:14] jam: ah, i thought you were referring to goamz/ec2 or environs/ec2, neither of which use json AFAIK [11:14] jam: perhaps he could try a little standalone program [11:14] rogpeppe: it is a bit unclear what the metadata service actually does, as I haven't studied the document and it goes back and forth between JSON and yaml. [11:14] It might depend on what specific URL is accessed. [11:15] dimitern: so my immediate hack would be to take out gzip (either everywhere or just for openstack), and then take out the certs, just to see if the instance node comes up [11:15] also, if you push your code, we can probably try to reproduce your findings. [11:16] dimitern: okay, add the following param server dict in goose: 'key_name': $OS_USERNAME [11:16] then make sure you have a key under that name (you should anyway) [11:16] dimitern: you could try reducing KeyBits in juju-core/cert to a small number, say 128 [11:16] then is you bootstrap with the borked cloudinit [11:16] dimitern: then the cloudinit will be significantly smaller [11:16] you'll be able to ssh in anyway, and then curl down the exact data the metadata service has [11:17] dimitern: it would be interesting to see if it still failed then [11:18] ok, one by one :) [11:19] rogpeppe: I'll try reducing the keybits first [11:19] jam: not sure how to remove the keys, otherwise removing gzip causes a failure on bootstrap every time [11:21] rogpeppe: live tests fail, looking for interesting tools: 1.9.8-unknown-amd64. [11:22] TheMue: ah of course [11:22] rogpeppe: not all fail, but 19 [11:22] TheMue: no ubuntu series on macos [11:22] rogpeppe: yep, exactly [11:23] TheMue: perhaps we can't expect live tests to pass under macos [11:23] rogpeppe: seems so [11:24] TheMue: unless we have an option to disable tools upload for the live tests, which might be a reasonable way to go [11:25] Hello! [11:25] dimitern: http://paste.ubuntu.com/1589367/ [11:25] mgz: I'll try that [11:26] niemeyer: Hiya [11:27] otherwise, reducing the keybits to 128 reduced the cloudinit almost in half, but still 48K uncompressed, so removing gzip doesn't help unless I somehow strip the keys [11:32] mgz: adding the key name didn't do the trick - still cannot connect with my key [11:33] mgz: dimitern: jam: standup? [11:37] mumble has decided it likes hanging... [11:52] mgz: I'd be more surprised if Hangout decided it likes to mumble [11:54] niemeyer: I hear mumbling all the time on hangouts :) [11:55] jam: :) [12:06] mgz: did it work for you with key_name? [12:14] dimitern: why don't you try making a little standalone program that starts an instance using nova and uses a custom-created cloudinit (you could still use juju-core/cloudinit) ? [12:14] dimitern: then it'll be easier to check without all the juju baggage [12:17] rogpeppe: i'm using lpsetup to start an instance with nova client and it's all ok [12:17] rogpeppe: the problem is I cannot find any way to connect to the borked cloudinit instance [12:17] dimitern: in that case, try it with gzipped user data [12:18] rogpeppe: without gzip bootstrap fails with 500 (too long) [12:18] dimitern: i mean try your standalone thingy with gzipped user data [12:18] rogpeppe: can I somehow strip the ca certs from the cloud init? [12:18] dimitern: sure, just hack the cloudinit package, it's trivial [12:18] rogpeppe: it's just marshaling into yaml the cfg [12:19] dimitern: make it so it doesn't use the same certs [12:20] rogpeppe: i'm not even sure which keys are the biggest [12:20] dimitern: just zero 'em all out [12:21] rogpeppe: which keys? [12:22] dimitern: something like this should do the job (untested): http://paste.ubuntu.com/1589462/ [12:23] rogpeppe: will state work with after this? [12:23] dimitern: no, but the instance will be started ok [12:23] dimitern: so you should be able to ssh to it [12:23] rogpeppe: ok, I'll try it [12:25] mgz: http://paste.ubuntu.com/1589468/ [12:30] so, cuter magic on metadata service folsome(?) or later: http://169.254.169.254/openstack/2012-08-10/meta_data.json [12:31] rogpeppe: when I set these to nil it says error: cannot start bootstrap instance: cannot make user data: invalid machine configuration: missing CA certificate [12:32] dimitern: did you use the snippet i suggested? [12:34] dimitern: so, this is double-base64 encoded [12:35] dimitern: are you base64 encoding inside environs/openstack ? [12:35] rogpeppe: yes. [12:35] well, no [12:35] but... it's happening *somewhere* :) [12:35] ha [12:36] rogpeppe: only goose encodes to base64 [12:39] wait a minute - there are 2 cloudinits - in juju-core/ and in juju-core/environs/ - the provider uses the latter [12:40] ...which uses the former actually [12:42] and there's this (line 151 in environs/cloudinit.go): " --env-config "+shquote(base64yaml(cfg.Config))+ [12:42] ...which is fine [12:49] dimitern: are you using Ian's RunServer-userData-fix branch? [12:49] mgz: don't think so [12:50] because this looks like something daft like the go json code being helpful by base64ing byte[] behind the scenes, after it's already been done [12:52] mgz: looks like if I remove the b64 encoding in runserver it works ok [12:52] mgz: could be! yeah - []byte to "64" [12:52] right, so the right fix is... remove 4 lines... [12:53] mgz: i did, but still not sure if it's right and we should fix something else instead [12:55] jam, dimitern: http://paste.ubuntu.com/1589539/ [12:55] yay! ssh now works! [12:55] exactly [12:55] I'm doing that in the CL then [12:55] a separate one for goose [12:56] so, Ian's mp which switches the type to string likely works as well [12:56] where's that branch? [12:57] dimitern: lp:~wallyworld/goose/RunServer-userData-fix [12:58] it is documented behaviour of the json go implementation though, so the use []byte and remove those lines versions is probably nicer [12:58] mgz: from go docs: Array and slice values encode as JSON arrays, except that []byte encodes as a base64-encoded string, and a nil slice encodes as the null JSON object. [12:58] :) yeah [12:59] mgz: actually, without these 4 lines ian's branch is not needed [13:00] right. but Ian wasn't wrong when he said he'd got it working [13:00] yes [13:00] we then just ignored him, so it broke for us :) [13:00] :) maybe I should NOT LGTM and provide that above reasons? [13:01] if in addition he did the gzip thing, his change would work [13:01] well, I think I'll put up a trivial branch that actually adds a test and removes those lines [13:02] cool, if you can land it before mine it'll be perfect [13:02] then we can reject the one that changes the RunServer interface, and update the enable openstack branch [13:03] yes, I also need that change [13:10] shouldn't mongo be running on the bootstrap node? [13:14] rogpeppe: ^^ ? [13:15] dimitern: yes, mongo should run on the bootstrap node, but it won't if you didn't have the server cert and key [13:16] I have this in /var/log/juju/machine-0.log: /bin/sh: 1: exec: /var/lib/juju/tools/machine-0/jujud: not found [13:16]