[01:37] <kl> what's the advantage of cloud-init over ansible?
[01:37] <kl> or rather, where would you use one tool over the other
[01:40] <larsks> kl: cloud-init runs when a system boots, *on that system*.  So, for example, if you need to install python first so that you could use ansible, cloud-init could take care of those package installations.  Or if you need to provision an ssh key before you are able to connect to the system, cloud-init can do that, too.
[01:40] <smoser> cloud-init has the ability to run earlier in boot than ansible. but for the most part its job is to get you to some other management system.
[01:40] <smoser> Odd_Bloke, if you're bored and want some cloud-init work (or ayone for that matter)
[01:40] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1427939
[01:41] <kl> larsks & smoser: thanks guys.
[01:41] <smoser> but you probalby hav ecloud-init in there somewhere.
[01:41] <smoser> thats the idea. even if all it does is set up ssh host keys
[01:41] <smoser> and ssh public keys so ansible can take over.
[01:43] <kl> That makes perfect sense
[01:43] <kl> Cheers again :)
[04:34] <faizal> How to add a blank line. ..With write_files
[12:45] <Odd_Bloke> smoser: Those Python 2.6 failures boil down (I think) to this lovely behaviour change: http://paste.ubuntu.com/10526494/
[13:32] <smoser> Odd_Bloke, oh joy
[13:32] <smoser> i guess its easy enougnh to check python version and address.
[13:32] <smoser> if thats it.
[13:41] <Odd_Bloke> smoser: Yeah, I've hit this before actually.
[13:41] <Odd_Bloke> The problem is that 2.6 uses cStringIO which doesn't handle Unicode.
[13:42] <Odd_Bloke> So it's an easy enough fix.
[13:42] <smoser> Odd_Bloke, htanks
[13:43] <Odd_Bloke> smoser: Review of https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix-dmi/+merge/251715 would be much appreciated; it's causing SmartOS to fail (and is probably (partially) behind the CloudSigma failures that bjf was seeing).
[13:47] <smoser> Odd_Bloke, thats very nice. thank you.
[13:47] <Odd_Bloke> :)
[13:59] <smoser> Odd_Bloke, the only ocmment i hvae on your code... i might be wront oo
[13:59] <smoser> er... 2 comments i guess.
[14:00] <smoser> a.) i might make it check that /sys path exists on input _read_dmi_syspath
[14:00] <smoser> ie, possibly the user doesnt know or care about the old dmidecode path.
[14:00] <smoser> maybe you have thoughts on that.
[14:00] <smoser> b.) LOG.debug("querying dmi data %s", dmi_key)
[14:01] <smoser>   is slightly faster (and consistent with outer cloud-init logging)
[14:01] <smoser>   than:
[14:01] <smoser>   LOG.debug("querying dmi data {0}".format(dmi_key))
[14:01] <smoser> in the case where LOG.debug is filtered out entirely, it will never do the string conversion
[14:01] <smoser> but consistency is probably a more real argument ther.e
[14:01] <Odd_Bloke> smoser: I did initially have the code trying /sys/.../mapping[key] and then /sys/.../key, in case people didn't want to hand a dmidecode thing over.
[14:03] <smoser> neither of the above are strong feelings of mine.
[14:03] <Odd_Bloke> smoser: OTP for a bit, will pick it up in a bit.
[15:28] <Odd_Bloke> smoser: So the reason that I backed out the 'see if the given key exists in /sys/... before trying dmidecode' is that we will have some places that /sys/... doesn't exist.
[15:28] <Odd_Bloke> smoser: But most people will be developing on places where it does.
[15:29] <Odd_Bloke> smoser: So we will see things breaking unexpectedly.
[15:29] <smoser> Odd_Bloke, im' fine with that argument
[15:30] <Odd_Bloke> I'll make the logging changes in a minute.
[16:09] <Odd_Bloke> smoser: Logging changes pushed up to https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix-dmi/+merge/251715
[16:12] <smoser> Odd_Bloke, i'll pull. thanks
[16:13] <Odd_Bloke> smoser: Thanks!
[17:24] <Odd_Bloke> smoser: https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix-py26/+merge/251784 fixes tests on Python 2.6.
[17:25] <Odd_Bloke> smoser: Tests still pass on 2.7, but I can't check 3.4 because of a test hang.
[17:25] <Odd_Bloke> smoser: Which is fixed in https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix-py34-test-hang/+merge/251725
[17:26] <smoser> Odd_Bloke, its probably udev related. 
[17:27] <smoser> the test hang... udevadm gets run in the tests. it really shouldnt
[17:27] <Odd_Bloke> smoser: It is, in fact, HTTPretty related.
[17:27] <smoser> oh.
[17:27] <Odd_Bloke> Though I'm not ruling out the existence of more than one hang. ;)
[17:27] <smoser> http_proxy= ?
[17:27] <smoser> the debian package unsets that explicilty
[17:27] <Odd_Bloke> smoser: Nope, something to do with it failing to monkey patch Python 3.4.2 correctly.
[17:28] <Odd_Bloke> Or, rather, failing to un-monkey-patch Python 3.4.2 correctly.
[17:28] <Odd_Bloke> (Because of a bug in Python 3.4.2)
[20:53] <stumped> Q: Using "write_files" to *append* to an existing file. I'm having troubles figuring out how to *append* to a file, no problems creating one. Can't seem to locate the method. Ideas?
[20:54] <smoser> i dont thhink you can append.
[20:55] <smoser> yeah, you cannot. it calls 
[20:55] <smoser>  util.write_file(path, contents, mode=perms)
[20:55] <smoser> it'd have to pass 'omode=wb+'
[20:56] <stumped> ah, i see. Thanks. End of that research then. :P I'll move it to a runcmd
[20:58] <stumped> Is there a special method of escaping the ">" characters? In a runcmd, I've tried adding the following text, but YAML appears to have problems with the ">"....
[20:59] <stumped> - "echo /tmp/afile.txt >> /tmp/anotherfile.txt"
[21:04] <smoser> hm..
[21:04] <smoser> inside the "" it doesnt like it?
[21:05] <stumped> doesn't seem to. I've tried a lot of different variants. My understanding is that a double-quote treats the entire string as literal.
[21:05] <stumped> sorry, the word "echo" should be "cat".
[21:09] <smoser> http://paste.ubuntu.com/10531218/
[21:09] <smoser> seems to not need anything special to me
[21:11] <smoser> stumped, ^
[21:12] <stumped> yes. I see. I'll play around with it more. Perhaps I made a mistake or it's something unique to the runcmd method of performing the systemcall to execute the string.
[21:35] <stumped> smoser: looks like my mistake. I believe I had a large "yum update" performing at the beginning of the runcmd list and it was still running when the system went into multiuser mode and I didn't realize it. I probably got myself confused by trying to escape >> with \>\> .. TL;dr; cascading set of errors made it look like it wasn't working.