[00:45] <dgarstang1> Has scripts been removed from cloud-init ?
[00:55] <harlowja> dgarstang1 can u describe that more, not sure how to answer that question :)
[08:37] <kwadronaut> opinions? should i generate a new hostid for popcorn for each virtual machine?
[08:38] <kwadronaut> popcon, not popcorn of course.
[13:30] <smoser> kwadronaut, that same question came up in another package recently.
[13:30] <smoser> i really kind of think you should.
[13:37] <kwadronaut> i'm thinking i agree. and i wonder if cloud-init should bother. i think it'd be straightforward but unsure if that could be a default debian tpl
[13:37] <kwadronaut> s/could/should
[13:39] <smoser> kwadronaut, maybe cloud-init should just put "intsance-id" into some standard place
[13:40] <smoser> and then things like popcon could just say:
[13:41] <smoser> [ -f /run/cloud-init/instance-id ] && HOSTID=$(cat /run/cloud-init/instance-id)$(WHATEVER_ELSE)
[13:42] <kwadronaut> cloud-init isn't the only player. but you're right that it could also be approached from the other side
[13:44] <kwadronaut> do you remember the other package with same/similar question?
[16:59] <dgarstang1> Has scripts been removed from cloud-init ?
[17:31] <smoser> kwadronaut, pollinate was the other thing
[17:31] <smoser> dgarstang1, what do yo umean ?
[17:33] <dgarstang1> smoser: Lemme find an example. one sec
[17:34] <dgarstang1> smoser: http://pastebin.com/Rf6YBu5L ... i just realised what's really going on here is a YAML anchor... but 'scripts' isn't a valid directive for cloud-init, so I assume it just ignores it
[17:35] <dgarstang1> and I'm pretty sure I can't put the scripts in one .d file, and the runcmd in another as yaml anchors in python aren't supported across multiple documents
[17:37] <smoser> ah. 
[17:37] <smoser> yeah, thats probalyb correct
[17:37] <dgarstang1> oki.
[17:39] <dgarstang1> should work if both are in the same file tho? still assuming cloud-init just ignores 'scripts:'... it always did in previous versions. :)
[17:39] <smoser> right. it does just ignore that.
[17:39] <dgarstang1> it's a lot easier to write it that way than eg: - [ ls, -l, / ]
[17:39] <smoser> yep.
[17:40] <smoser> dgarstang1, 
[17:40] <smoser> http://paste.ubuntu.com/6839095/
[17:40] <smoser> that is my default user-data
[17:40] <dgarstang1> most of that's gonna go in chef land. :)
[17:41] <smoser> yeah, which is perfectly good.
[17:41] <dgarstang1> :)
[17:42] <smoser> i was just pointing at it as an example of the anchor use
[17:42] <dgarstang1> but I assume 'sm_misc:' is the same dealio as 'scripts:' ?
[17:43] <smoser> yeah.
[17:43] <smoser> name it __anchorforyaml if you want
[17:44] <dgarstang1> kk
[18:59] <dgarstang1> ugh. not having much luck with scripts. i can't even tell if it's running. how can I tell?
[19:03] <smoser> dgarstang1, version ?
[19:03] <smoser> the yaml thing shoudl work. 
[19:03] <smoser> it populates /var/lib/cloud/instance/scripts/
[19:03] <smoser> in the 'config' run i think.
[19:03] <smoser> and then runs them in the final
[19:05] <dgarstang1> smoser: I think the issue is that when a script fails to run, there's totally no idea why, and no output from the script
[19:05] <smoser> dgarstang1, it goes to /dev/console on ubuntu
[19:06] <smoser> but you can (and probalby should) change the output of cloud-init via 'output:' config
[19:06] <smoser> to go to /var/log/cloud-init-output.log as in my paste above
[19:06] <smoser> so that scripts run by it will have stdout and stderr tee'd to that file.
[19:06] <dgarstang1> smoser: kk. That'd be useful, thanks
[19:06] <smoser> (that is now the default behavior in 0.7.5)
[19:07] <dgarstang1> never quite got that to work before. I'll try again
[19:08] <dgarstang1> wouldn't output have to go EARLY in the config?
[19:08] <smoser> well, not really.
[19:08] <smoser> it reads all config and then acts on it.
[19:09] <dgarstang1> oki
[19:09] <dgarstang1> tanx
[19:15] <smoser> there are some things that are tricky to get into the config via user-data. (ie, they kind of have to be there alredy)
[19:15] <smoser> such as datasource settings (like what url to look at, or what datasources to search for)
[19:15] <smoser> those are just kinda hard to pass in via a datasource :)
[19:32] <harlowja> smoser back to why need config-drive question
[19:32] <harlowja> http://bazaar.launchpad.net/~harlowja/cloud-init/ds-openstack/view/head:/cloudinit/sources/helpers/openstack.py#L302
[19:32] <harlowja> basically that code there just switches loading based on finding config drive or reading from metadata
[19:32] <harlowja> so this new DSOpenstack can search for config drive in local mode
[19:32] <harlowja> and also search for metadata service in net mode
[19:32] <harlowja> so thats part of why we could just remove DSConfigDrive
[19:33] <harlowja> since really they are the same data :-P
[19:33] <smoser> just pushed to trunk vendor-data support into nocloud
[19:34] <smoser> ah. yeah, i see.
[19:34] <smoser> i didnt understand your question before.
[19:34] <harlowja> np
[19:34] <smoser> it'd be nice to somehow support the explicitly configured DataSourceConfigDrive
[19:35] <harlowja> dont run DSOpenstack in net mode :-/
[19:35] <smoser> right. but i'm saying upgrade.
[19:35] <smoser> or old configs
[19:35] <harlowja> ah
[19:35] <harlowja> sure
[19:37] <harlowja> there aren't to many unique configs that are special, so it should be possible
[19:51] <smoser> harlowja, mainly i was ust saying the list of datasources to search into
[19:52] <smoser> someone would have had 'ConfigDrive'
[19:52] <smoser> and your patch woudl then no longer work.
[19:53] <harlowja> right
[19:53] <harlowja> np to solve that