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