| domovoy | hi | 10:19 |
|---|---|---|
| domovoy | i'm currently creating some custom images using packer to simplify my deployments. The idea is that the image would install apps from git repos using metadata provided to cloud-init by the cloud provider ot user | 10:22 |
| domovoy | for that i would just need some script to run on per-instance; what would be the 'right' way to achieve that? | 10:23 |
| domovoy | from the docs i see 2 possibilities: | 10:24 |
| domovoy | add a script in .../scripts/ ; but as i get it, those scripts should be created from a module/part-handler, not 'simply exists' | 10:26 |
| domovoy | create a custom module ; but as i get it, that would mean modify cloud-init sources and install that modified version | 10:27 |
| domovoy | isn't there a way to simply say 'this cloud-init installation runs <command> on per-instance"? | 10:28 |
| domovoy | adding a custom module without the need for an installation from modified sources would be the ideal solution, can that be done? | 10:34 |
| domovoy | targeted use case: automatically clone repositories, checkout a specific 'version', and run provisioning script. based on digitalocean tags set on the instance. ideally the script should run every time those tags changes, in order to uninstall 'disappeared' tags, and install new ones (but i can live with it running only on droplet creation) | 10:42 |
| === domovoy_ is now known as domovoy | ||
| holmanb | domovoy: making your own module would be a lot of work | 14:26 |
| holmanb | domovoy: take a look at this module, it does what you want https://cloudinit.readthedocs.io/en/latest/reference/modules.html#runcmd | 14:28 |
| domovoy | holmanb: runcmd would allow me to run a custom command, sure, but it still need to be setup from cloud or user data. or is there a way to make it so that it's part of the base config, no matter what is provided by cloud or user? | 15:37 |
| minimal | domovoy: aren't "run on per-instance" and "should run every time those tags change" contradictory? | 16:02 |
| domovoy | minimal: not according to https://cloudinit.readthedocs.io/en/latest/development/module_creation.html | 16:07 |
| domovoy | "PER_INSTANCE: Runs once per instance. When exactly this happens is dependent on the datasource, but may triggered any time there would be a significant change to the instance metadata. An example could be an instance being moved to a different subnet." | 16:08 |
| minimal | AFAIK per-instance refers to the instance id changing | 16:09 |
| minimal | which typically happens when cloud-init runs on 1st boot (or if you "clean up" cloud-init so that it runs again from fresh on next boot) | 16:10 |
| minimal | you'll see instance id's logged in /var/log/cloud-init.log and in /var/lib/cloud/cloud/instances/ | 16:11 |
| domovoy | as i understand it, the datasource may also make it happen whenever it decides there are changes that warrant it, probably by changing the instance id actually | 16:11 |
| minimal | right, I did say "typically" earlier ;-) I'm not sure which datasources tend to change the instance id | 16:12 |
| domovoy | me neither, which is why this "every time the tags change" part is considered the ideal case, and i said i'd be happy with it happening only on instance creation | 16:13 |
| minimal | if you want it to run every time have you looked at placing the script in /var/lib/cloud/scripts/per-boot/ ? | 16:13 |
| domovoy | yeah, i've considered placing a scripts in the ...scripts/ directory, but the doc states "Scripts in one of these subdirectories are downloaded/created by the corresponding part-handler"; so placing "permanent" scripts there out the cloud-init process seems like it's not the "right" way | 16:15 |
| domovoy | i could also create an init script which would query cloud-init metadata, there are actually many ways i could achieve my goal. my question is about what would be "normal, as thought by the devs, cloud-init way" | 16:17 |
| minimal | just tested by creating a simple shellscript in /var/lib/cloud/scripts/per-boot/ and making it executable, then rebooted, and it ran as expected | 16:19 |
| domovoy | i know it works, still not my point, and from the doc, not the way those directories should be used | 16:20 |
| minimal | I think the docs are perhaps incorrect or misleading | 16:25 |
| domovoy | wat makes you think that? | 16:25 |
| minimal | from a quick look at the source code of various DataSources the only one that makes reference to /var/lib/cloud/scripts is the SmartOS one | 16:25 |
| minimal | which refers to vendor-data being a boothook to write a script into per-boot | 16:26 |
| domovoy | datasources maybe, but part handlers definitely write scripts there | 16:26 |
| domovoy | https://cloudinit.readthedocs.io/en/latest/explanation/format.html#mime-multi-part-archive | 16:28 |
| minimal | that's referring to one of the formats of user-data | 16:31 |
| domovoy | the mime-multipart format, which is handled by... part handlers | 16:32 |
| minimal | yes, when you provide mime-multipart format as the user-data | 16:32 |
| domovoy | which, according to the doc, is what is supposed to put script is ...scripts/ subdirectories | 16:33 |
| domovoy | "Scripts in one of these subdirectories are downloaded/created by the corresponding part-handler" | 16:33 |
| minimal | I wasn't referring to providing a per-boot script via user-data, I was referring to writing a script directly to /var/lib/cloud/scripts/per-boot/ as part of your Packer image creation | 16:33 |
| domovoy | yes, and again, the doc says that's not how those directories are supposed to be used... | 16:34 |
| minimal | I'm saying that I *think* the docs are misleading and should instead say "Scripts in one of these subdirectories can be downloaded/created by the corresponding part-handler" | 16:34 |
| domovoy | i haven't found nothing in the doc saying cloud-init is supposed to handle cases when a script is placed there out of its process, i only found indication of the opposite actually | 16:35 |
| minimal | and perhaps also explicitly say "or you can place scripts directly there during image creation" | 16:35 |
| domovoy | that would indeed solve my problem | 16:35 |
| domovoy | but unless confirmed otherwise, i can only believe the doc | 16:36 |
| minimal | you're assuming the docs are 100% correct and that anything not indicated by the docs are not permitted/intended....which may or may not be correct, I don't know, that's for one of the Canonical guys to comment on | 16:36 |
| domovoy | i'm assuming nothing, hence me asking | 16:36 |
| minimal | best to ask on a week day as the Canonical guys don't tend to be around on weekends | 16:36 |
| domovoy | just so that my request is clear for everyone: i'm asking how it _should_ be done, not how it _can_ be done. thanks | 16:42 |
| domovoy | hmmm, although not stated explicitely, https://cloudinit.readthedocs.io/en/latest/reference/base_config_reference.html gives an example with a `users` setting, which would hint that those files can contain not only the keys listed on this page, but also modules configs | 18:20 |
| domovoy | Is that accurate? | 18:20 |
| domovoy | It would allow me to create a file in /etc/cloud/cloud.cfg.d/, which would include a `runcmd` command, and hence run my command the "cloud-init" way | 18:21 |
| minimal | as indicated at the top of that page this is the base configuration for cloud-init (i.e. where you define which modules it may attempt to run etc) | 18:23 |
| minimal | so you'll see "runcmd" mention in the example "cloud_config_modules:" section which indicates that the runcmd module should be run during the "config" cloud-init stage | 18:24 |
| domovoy | minimal: i was talking about things like `preserve_hostname: false` in the final example on the page, `preserve_hostname` is not a base config key, but a module config one. so this hints that modules configs can also be part of those files | 18:40 |
| minimal | as is "disable_root" | 18:41 |
| minimal | but to turn your previous reasoning back on you, the docs do not say setting arbitrary module configs there is supported ;-) | 18:42 |
| domovoy | yes, but the doc doesn't state explicitely that modules configs can be part of those files, so... can they? or is there just a few special cases accepted? or is the example wrong? or... | 18:42 |
| domovoy | minimal: exactly, which is why i ask if this behavior is actually accurate | 18:43 |
| minimal | no idea | 18:44 |
| minimal | depends on whether the docs are written from a "common law" (what is not forbidden is permitted) or "civil law" (what is permitted is defined, everything else is forbidden) perspective ;-) | 18:49 |
| domovoy | well to be honest, i always found that cloud-init doc lacks a lot of info... i've always ended up reading the sources to understand how it works. but that's quite a "hacky" way to go, which is why i'm here now, hoping some cloud-init guru can tell how it _should_ be done | 18:53 |
| domovoy | eventually if i decide to actually use cloud-init for my project, i'll create some issues about all that | 18:54 |
| domovoy | but at this point... seems to me that simply creating an init script and forget about cloud-init would be way easier and reliable | 18:55 |
| minimal | you mentioned you're running on DO so I assume you'll still need cloud-init in the OS image for DO-related config | 18:59 |
| domovoy | i am on DO yes, but the idea is not to be tied to it, but provide a generic image made with packer that would behave the same on other cloud providers | 19:01 |
| minimal | right, my point is that typically "cloud providers" means having cloud-init in the OS image | 19:01 |
| domovoy | well cloud-init being in the image doesn't mean i _have_ to use it | 19:02 |
| domovoy | or that i have to find convoluted ways to integrate with it | 19:02 |
| domovoy | i.e. an init script that run at the right time can still query cloud-init metadata and act according to it | 19:03 |
| minimal | correct, I was just clarifying whether you meant removing cloud-init from the OS image | 19:03 |
| domovoy | na, any cloud provider will rely on it, it has to stay | 19:04 |
| minimal | which DataSource are you using for DO BTW? | 19:08 |
| domovoy | actually that init script would make things quite easy. i'm just investigating if there is a way to make my code part of the cloud-init process, with the idea of having any cloud related task in the same place | 19:09 |
| domovoy | minimal: i haven't checked that yet, i also discovered that the DigitalOcean datasource is considered deprecated XD | 19:10 |
| minimal | yes, I was the one who brought up the issue that DO themselves didn't seen to be using the DO datasource and used ConfigDrive instead, which lead to the deprecation | 19:11 |
| domovoy | it seems a lot of cloud providers use ConfigDrive | 19:12 |
| minimal | I wouldn't say that myself, it tends to be used mainly for OpenStack deployments | 19:14 |
| === domovoy__ is now known as domovoy | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!