[00:18] <bassamt> hi, cloud-init is failing on init for me with the following error UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 0: invalid start byte
[00:19] <bassamt> version 0.7.7 from an Ubuntu 15.10 AMI.
[00:20] <bassamt> any ideas for how I can debug the issue? user-data in AWS does look weird (and not something I can change)
[06:29] <SuperLag> this is all I have in my cloud.cfg file http://pastebin.com/FrWTnHLf and when I try to SSH, it still asks for a password. What am I doing wrong? :/
[08:08] <SuperLag> I've changed it to be the stock file with only the stuff I needed included. It still doesn't work.
[08:08] <SuperLag> I clearly don't have a clue, and I'm at the end of my rope.
[08:08] <SuperLag> I'd be *happy* to pay someone to help me figure this out.
[11:30] <xael> hello all, i am Alex from Bigstep, currently working on adding a new datasource for the Bigstep cloud service and to also port our templates into using cloudinit
[11:31] <Odd_Bloke> xael: Hola!  (I'm Dan Watkins from Canonical. :)
[11:32] <xael> currently, I am having a problem with changing the password for the root user on a CentOS 6.6 machine running cloud-init 0.7.5
[11:32] <xael> by sending it in a hashed form, not plaintext
[11:36] <xael> the way in which i managed to do it was to add an 'hashed_passwd' option in distros/__init__ and use the existing set_password with the hashed parameter set
[11:44] <Odd_Bloke> xael: Can you pastebin the patch?  (Probably easier for me to grok that way :)
[11:46] <xael> http://pastebin.com/1j1yzxYB here you go, i pasted the whole function
[11:49] <Odd_Bloke> xael: That looks pretty sensible. :)
[11:52] <xael> what do you mean by sensible?:))
[11:52] <Odd_Bloke> xael: I mean: That looks like a change we should include in cloud-init. ^_^
[11:53] <xael> :D
[11:56] <xael> Odd_Bloke: did you manage to look over the datasource I sent you before the holidays?
[12:17] <Odd_Bloke> xael: I didn't, I think that must have got lost in the shuffle, I'm afraid.
[12:17] <Odd_Bloke> xael: Could you send it over again?
[12:20] <xael> of course
[12:21] <Odd_Bloke> xael: Sorry about that!
[12:21] <xael> no problem :D
[12:25] <xael> sent, could you please tell me if you received it?
[12:29] <Odd_Bloke> xael: Received; thanks. :)
[12:29] <Odd_Bloke> xael: I doubt I'll be able to get to it today, but I'll try to have a look on Monday. :)
[12:31] <xael> no rush
[12:36] <Odd_Bloke> :)
[12:51] <atonal> Hello, is user-data supposed to merge with stuff from /etc/cloud/cloud.cfg?
[12:51] <atonal> I have merge_type: 'list(append)+dict(recurse_array)+str()' in the user-data, but merge doesn't seem to happen
[13:08] <larsks> atonal: what in particular are you trying to merge?
[13:20] <atonal> larsks: some users
[14:28] <atonal> If I have two separate configs in the heat template with merge_type, they merge together fine, but stuff from /etc/cloud/cloud.cfg is missing
[14:28] <atonal> And if I remove the configs from the heat template, I get the stuff from /etc/cloud/cloud.cfg
[14:29] <smoser> atonal, can you show what you have in user data ?
[14:48] <larsks> smoser: I think I can replicate the problem.  I'm using this: http://chunk.io/f/6d69899a5f95470a8248256b731848bf
[14:48] <larsks> smoser: that seems to be *replacing* the users: block in /etc/cloud/cloud.cfg, rather than merging.
[14:48] <atonal> yes, that's close to what I have
[14:49] <larsks> (on my test systems, the users: block in cloud.cfg contains only "- default"
[14:49] <larsks> )
[14:51] <larsks> atonal: for what it's worth, I've always found the merging support in cloud-init to be confusing at best.  smoser and I have had several discussions where the outcome was "huh, I guess that won't work".
[14:51] <atonal> Confusing it definitely is.
[14:54] <smoser> larsks, i agree with you
[14:54] <smoser> :)
[14:55] <smoser> the merging is fairly straight forward for dict
[14:55] <smoser> and generally does the right thing
[14:55] <smoser> but for lists, its wierd. and by default it just replaces lists.
[14:57] <atonal> But in general, merging user data and /etc/cloud/cloud.cfg _should_ work? Or is this some undefined-behavior-land?
[15:00] <smoser> yeah.. but ther are some caviats.
[15:00] <smoser> caveats
[15:00] <smoser> atonal, for testing you can do this
[15:00] <smoser> PYTHONPATH=$PWD ./tools/ccfg-merge-debug config/cloud.cfg cc.cfg  > out.1
[15:00] <smoser> just from trunk. it will output a merged file.
[15:00] <larsks> atonal: I have never been able to successfully merge something with cloud.cfg, although i was trying to modify things like cloud_init_modules which if I recall are simply parsed too early in the process or something like that.
[15:01] <smoser> i did hyave to change the config/cloud.cfg to have '#cloud-config' at the top or it doesn't get considered cluod-config.
[15:01] <smoser> init_modules is parsed too early
[15:01] <smoser> but config_modules and final_modules can work..
[15:02] <larsks> ...although those are lists, like users:, and since the users merge doesn't seem to be working even with list(append), I'm wondering if those will work.  I guess that's a quick test...
[15:04]  * larsks tests.
[15:06] <smoser> actually... init_modules should be able to be re-written too.
[15:07] <larsks> smoser: you and I had looked at something like that in the past and discovered that I think it wouldn't work.  I thought.
[15:07] <larsks> I'd have to see if I still have the irc logs...
[15:09] <smoser> yeah. i think there is an issue with merging over builtin configs.
[15:09] <smoser> but i thoguth i would have ahd a bug on it and i dont see it.
[15:11] <larsks> smoser: so, e.g, this appears to just override cloud_config_modules rather than appending: http://chunk.io/f/f3325b6193234a87a8ac4c1fa9604966
[15:14] <SuperLag> I am still having issues getting my config to work. I just want to specify a user, and set up specific SSH keys for that user, and have that go into each instance I spin up. My config is at http://pastebin.com/ekjhZAEr.
[15:16] <SuperLag> Do you need to include every section in your cloud.cfg, and just leave the non-relevant parts blank? or do you only include the parts that you need?
[15:18] <smoser> larsks, yeah, thats the issue. the merges only apply to config coming in in user-data.
[15:18] <smoser> which would also be why the users dont work as expected.
[15:18] <smoser> could you open a bug, just point to your data. i'd like to fix that.
[15:19] <larsks> smoser: sure.
[15:22] <larsks> smoser: https://bugs.launchpad.net/cloud-init/+bug/1532234
[15:22] <smoser> SuperLag, the data you have there is not valid yaml
[15:23] <smoser> there is probably a WARN message to this affect in /var/log/cloud-init.log
[15:23] <smoser> but you can easily test yaml just with:
[15:23] <smoser>  python -c 'import yaml, sys; yaml.load(open(sys.argv[1]).read())' foo.yaml
[15:23] <smoser> now, that said, i'm not certain that ssh keys are added to a user if the user is not created. let me check
[15:24] <smoser> it should.
[15:24] <smoser> larsks, that is awell written bug report
[15:24] <smoser> thank you.
[23:10] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Change stackforge to openstack  https://review.openstack.org/256684
[23:10] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Update .gitreview for new namespace  https://review.openstack.org/236289
[23:11] <openstackgerrit> Joshua Harlow proposed openstack/cloud-init: Update stackforge to openstack  https://review.openstack.org/237452
[23:19] <openstackgerrit> Merged openstack/cloud-init: py26 is no longer supported by Infra's CI  https://review.openstack.org/261718
[23:26] <openstackgerrit> Merged openstack/cloud-init: Deprecated tox -downloadcache option removed  https://review.openstack.org/256694
[23:49] <openstackgerrit> Merged openstack/cloud-init: Update stackforge to openstack  https://review.openstack.org/237452