[00:32] <anotheral> hey can anyone help me figure out why my cloud-config isn't working?
[00:33] <anotheral>  /var/lib/cloud/instances/i-dca1cb75/user-data.txt has base64-encoded text
[00:33] <anotheral> that decodes to a #cloud-config file
[13:19] <smoser> anotheral, it shouldnt be base64 encoded there.
[14:53] <Odd_Bloke> smoser: I'd like to submit a talk to LinuxCon Europe/CloudOpen Europe (they're running at the same time in the same place); I was thinking that cloud-init 2.0 would be a good topic.
[14:53] <Odd_Bloke> smoser: Would you be able to help me craft a talk proposal?
[14:57] <smoser> sure
[16:36] <Odd_Bloke> smoser: CFP ends tomorrow; I'll try and come up with something tomorrow morning, and we can maybe discuss it on/just after the 2.0 call?
[16:36] <Odd_Bloke> smoser: (I've fixed the tests on that CloudStack MP)
[16:36] <smoser> ok
[16:41] <smoser> Odd_Bloke, pulled
[16:42] <Odd_Bloke> smoser: Thank you, sir.
[16:43] <Odd_Bloke> I'll look at backporting it tomorrow also.
[16:44] <Odd_Bloke> smoser: Are you able to add all the releases back to precise as targets on https://bugs.launchpad.net/cloud-init/+bug/1464253 ?
[16:45] <smoser> oh. you marked that security.
[16:46] <smoser> why is that different then the non-security one ?
[16:46] <smoser> (i had thought it was the cpc bug or something)
[16:46] <Odd_Bloke> smoser: The other bug is actually about doing it every boot (which I don't think we want to be the default).
[16:46] <smoser> oh. i see.
[16:46] <Odd_Bloke> smoser: Someone just noted the security issue in the comments of that bug.
[16:47] <smoser> well, why idd you mark 'fixes'
[16:47] <smoser> which made me mark fixes ;)
[16:47] <Odd_Bloke> >.<
[16:48] <Odd_Bloke> Apologies.
[16:48] <Odd_Bloke> Wasn't it easier when I use git-bzr-ng and couldn't use --fixes at all. ;)
[16:56] <Odd_Bloke> smoser: Do you mind if I assign doing the devel release to you?
[17:00] <smoser> context ?
[17:00] <Odd_Bloke> smoser: The release of that security fix in to wily.
[18:05] <jgarr> I have a redhat atomic host I'm trying to run subscription-manager register on via runcmd but it doesn't appear to run and there's no output in /var/log/cloud-init.log (debug: true is set)
[18:06] <jgarr> other commands in runcmd work though. Is there a way I can tell cloud-init to parse a user-data file again so I can see it run and try to debug it?
[18:08] <jgarr> running the command manually after the system is booted works without issue
[18:33] <ByPasS> alexpilotti : Hi there, smoser told me yesterday you might have a better idea for my issue, any chance you being around ?
[18:46] <smoser> jgarr, runcmd stuff is run in 2 parts.
[18:50] <smoser> jgarr, so.. the first part, writes /var/lib/cloud/instance/scripts/runcmd from what it finds in user-data
[18:50] <smoser> so you can check to see that you have that file
[18:52] <smoser> that part is the 'runcmd' config job. it can be regenerated by:
[18:52] <smoser>  cloud-init single --name=runcmd --frequency=always
[18:53] <smoser> the second part is in scripts_user
[18:53] <smoser> and it actually executes (via run-parts style) all programs in /var/lib/cloud/instance/scripts/runcmd
[18:53] <smoser> that can be executed:
[18:54] <smoser>  cloud-init single --name=scripts_user --frequency=always
[20:59] <jgarr> smoser: thanks a ton for that. I'll look at my host and see what I have
[21:23] <anotheral> smoser: i removed the base64 encoding, but it still doesn't set the hostname
[22:20] <jgarr> smoser: sure enough. the runcmd file doesn't exist. runing cloud-init single doesn't generate it either. Now to figure out why
[22:20] <jgarr> may be helpful to say I'm also doing this on hardware with --append"ds=nocloud\;seedfrom=/var/cloud-init/" and then putting meta-data and user-data in /var/cloud-init/