dgarstang1 | Has scripts been removed from cloud-init ? | 00:45 |
---|---|---|
harlowja | dgarstang1 can u describe that more, not sure how to answer that question :) | 00:55 |
=== harlowja is now known as harlowja_away | ||
kwadronaut | opinions? should i generate a new hostid for popcorn for each virtual machine? | 08:37 |
kwadronaut | popcon, not popcorn of course. | 08:38 |
smoser | kwadronaut, that same question came up in another package recently. | 13:30 |
smoser | i really kind of think you should. | 13:30 |
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:37 |
smoser | kwadronaut, maybe cloud-init should just put "intsance-id" into some standard place | 13:39 |
smoser | and then things like popcon could just say: | 13:40 |
smoser | [ -f /run/cloud-init/instance-id ] && HOSTID=$(cat /run/cloud-init/instance-id)$(WHATEVER_ELSE) | 13:41 |
kwadronaut | cloud-init isn't the only player. but you're right that it could also be approached from the other side | 13:42 |
kwadronaut | do you remember the other package with same/similar question? | 13:44 |
dgarstang1 | Has scripts been removed from cloud-init ? | 16:59 |
smoser | kwadronaut, pollinate was the other thing | 17:31 |
smoser | dgarstang1, what do yo umean ? | 17:31 |
dgarstang1 | smoser: Lemme find an example. one sec | 17:33 |
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:34 |
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:35 |
smoser | ah. | 17:37 |
smoser | yeah, thats probalyb correct | 17:37 |
dgarstang1 | oki. | 17:37 |
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:39 |
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:40 |
smoser | yeah, which is perfectly good. | 17:41 |
dgarstang1 | :) | 17:41 |
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:42 |
smoser | yeah. | 17:43 |
smoser | name it __anchorforyaml if you want | 17:43 |
dgarstang1 | kk | 17:44 |
=== harlowja_away is now known as harlowja | ||
dgarstang1 | ugh. not having much luck with scripts. i can't even tell if it's running. how can I tell? | 18:59 |
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:03 |
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:05 |
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:06 |
dgarstang1 | never quite got that to work before. I'll try again | 19:07 |
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:08 |
dgarstang1 | oki | 19:09 |
dgarstang1 | tanx | 19:09 |
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:15 |
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:32 |
harlowja | since really they are the same data :-P | 19:33 |
smoser | just pushed to trunk vendor-data support into nocloud | 19:33 |
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:34 |
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:35 |
harlowja | there aren't to many unique configs that are special, so it should be possible | 19:37 |
smoser | harlowja, mainly i was ust saying the list of datasources to search into | 19:51 |
smoser | someone would have had 'ConfigDrive' | 19:52 |
smoser | and your patch woudl then no longer work. | 19:52 |
harlowja | right | 19:53 |
harlowja | np to solve that | 19:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!