/srv/irclogs.ubuntu.com/2023/10/22/#cloud-init.txt

domovoyhi10:19
domovoyi'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 user10:22
domovoyfor that i would just need some script to run on per-instance; what would be the 'right' way to achieve that?10:23
domovoyfrom the docs i see 2 possibilities:10:24
domovoyadd a script in .../scripts/ ; but as i get it, those scripts should be created from a module/part-handler, not 'simply exists'10:26
domovoycreate a custom module ; but as i get it, that would mean modify cloud-init sources and install that modified version10:27
domovoyisn't there a way to simply say 'this cloud-init installation runs <command> on per-instance"?10:28
domovoyadding a custom module without the need for an installation from modified sources would be the ideal solution, can that be done?10:34
domovoytargeted 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
holmanbdomovoy: making your own module would be a lot of work14:26
holmanbdomovoy: take a look at this module, it does what you want  https://cloudinit.readthedocs.io/en/latest/reference/modules.html#runcmd14:28
domovoyholmanb: 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
minimaldomovoy: aren't "run on per-instance" and "should run every time those tags change" contradictory?16:02
domovoyminimal: not according to https://cloudinit.readthedocs.io/en/latest/development/module_creation.html16: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
minimalAFAIK per-instance refers to the instance id changing16:09
minimalwhich 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
minimalyou'll see instance id's logged in /var/log/cloud-init.log and in /var/lib/cloud/cloud/instances/16:11
domovoyas 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 actually16:11
minimalright, I did say "typically" earlier ;-) I'm not sure which datasources tend to change the instance id16:12
domovoyme 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 creation16:13
minimalif you want it to run every time have you looked at placing the script in /var/lib/cloud/scripts/per-boot/ ?16:13
domovoyyeah, 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" way16:15
domovoyi 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
minimaljust tested by creating a simple shellscript in /var/lib/cloud/scripts/per-boot/ and making it executable, then rebooted, and it ran as expected16:19
domovoyi know it works, still not my point, and from the doc, not the way those directories should be used16:20
minimalI think the docs are perhaps incorrect or misleading16:25
domovoywat makes you think that?16:25
minimalfrom a quick look at the source code of various DataSources the only one that makes reference to /var/lib/cloud/scripts is the SmartOS one16:25
minimalwhich refers to vendor-data being a boothook to write a script into per-boot16:26
domovoydatasources maybe, but part handlers definitely write scripts there16:26
domovoyhttps://cloudinit.readthedocs.io/en/latest/explanation/format.html#mime-multi-part-archive16:28
minimalthat's referring to one of the formats of user-data16:31
domovoythe mime-multipart format, which is handled by... part handlers16:32
minimalyes, when you provide mime-multipart format as the user-data16:32
domovoywhich, according to the doc, is what is supposed to put script is ...scripts/ subdirectories16:33
domovoy"Scripts in one of these subdirectories are downloaded/created by the corresponding part-handler"16:33
minimalI 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 creation16:33
domovoyyes, and again, the doc says that's not how those directories are supposed to be used...16:34
minimalI'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
domovoyi 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 actually16:35
minimaland perhaps also explicitly say "or you can place scripts directly there during image creation"16:35
domovoythat would indeed solve my problem16:35
domovoybut unless confirmed otherwise, i can only believe the doc16:36
minimalyou'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 on16:36
domovoyi'm assuming nothing, hence me asking16:36
minimalbest to ask on a week day as the Canonical guys don't tend to be around on weekends16:36
domovoyjust so that my request is clear for everyone: i'm asking how it _should_ be done, not how it _can_ be done. thanks16:42
domovoyhmmm, 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 configs18:20
domovoyIs that accurate?18:20
domovoyIt 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" way18:21
minimalas 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
minimalso 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 stage18:24
domovoyminimal: 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 files18:40
minimalas is "disable_root"18:41
minimalbut to turn your previous reasoning back on you, the docs do not say setting arbitrary module configs there is supported ;-)18:42
domovoyyes, 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
domovoyminimal: exactly, which is why i ask if this behavior is actually accurate18:43
minimalno idea18:44
minimaldepends 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
domovoywell 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 done18:53
domovoyeventually if i decide to actually use cloud-init for my project, i'll create some issues about all that18:54
domovoybut at this point... seems to me that simply creating an init script and forget about cloud-init would be way easier and reliable18:55
minimalyou mentioned you're running on DO so I assume you'll still need cloud-init in the OS image for DO-related config18:59
domovoyi 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 providers19:01
minimalright, my point is that typically "cloud providers" means having cloud-init in the OS image19:01
domovoywell cloud-init being in the image doesn't mean i _have_ to use it19:02
domovoyor that i have to find convoluted ways to integrate with it19:02
domovoyi.e. an init script that run at the right time can still query cloud-init metadata and act according to it19:03
minimalcorrect, I was just clarifying whether you meant removing cloud-init from the OS image19:03
domovoyna, any cloud provider will rely on it, it has to stay19:04
minimalwhich DataSource are you using for DO BTW?19:08
domovoyactually 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 place19:09
domovoyminimal: i haven't checked that yet, i also discovered that the DigitalOcean datasource is considered deprecated XD19:10
minimalyes, 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 deprecation19:11
domovoyit seems a lot of cloud providers use ConfigDrive19:12
minimalI wouldn't say that myself, it tends to be used mainly for OpenStack deployments19:14
=== domovoy__ is now known as domovoy

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!