[01:39] Hola all. Revisiting a question of mine from ealier today ... [01:39] I have a VPS on OVHCloud. They use cloud-init. Data Source = OpenStack. I see no obvious onramps like AWS/EC2 provides to make cloud-init initialize an instance with my scripts. How does one do this? Thanks! [07:00] From the code, the systemd services, and cloud-init --help, it looks like scripts are run during the final stage, which can be manually invoked by cloud-init modules --mode final. But, despite spending some time (re)visiting main.py, stages.py, cc_script_user.py, etc, I can't quite figure out how cloud-init 'knows' it's already run a per-instance script so it knows not to run it again. Thanks! [07:38] beantaxi: [07:39] that knowledge is stored in /var/lib/cloud-init [07:39] cloud-init and can be mademade to forget [16:08] meena: Thanks you ... I'm not seeing /var/lib/cloud-init. [16:09] ('thanks you' ... good heavens) [16:20] I do see a /var/lib/cloud/sem/ which looks like it might be relevant [16:35] From a look at some of the code in helpers.py, around Runners and FileSemaphores and such, it looks as though it's checking for files in that folder and bailing if they already exist. [16:43] And my /v/l/c/sem folder has one file named config_scripts_per_once.once. So I guess I _cloud_ just copy script files to /v/l/c/s/per-* folders, but that seems a little hacky, and that I'd be better off creating a proper cloud config file or gzip and coercing cloud-init to work with that file [16:44] How might I do that? [16:51] beantaxi, yes, i got the folder wrong, but in there there's all the info cloud-init needs to decide whether it needs to run or not [20:23] meena: Thanks! I was offline for a few hours, so I may have missed some messages. But now that I have some more clues, I'm going to reread the docs and see what clicks. [21:00] K. So it looks like I can create my userdata file with make-mime as per usual ... copy it to /var/lib/cloud/instance ... then follow a few cloud init steps from the FAQ ... and then reboot, and my initialization script should get executed. [21:00] One question: how exactly does cloud-init know its been run per-instance? The /v/l/c/sem folder has a per.once file but that's it. Thanks! [21:09] we had that recently documented [21:09] let me see if i can find it [21:15] https://cloudinit.readthedocs.io/en/latest/topics/faq.html that's a good start [21:17] https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination [21:23] Thanks ... I read that and the First Boot Determination as well. They were both very helpful, but neither had detail on what file is used to indicate the instance has already booted. But perhaps that is the point of the /var/lib/cloud/instance/sem folder, as opposed to the /var/lib/cloud/sem folder? (I just now found the instance level sem folder) [21:47] they should just be links to each other [21:49] see, in theory, something in your virtual machine could change, and then your cloud decides this is a new instance and it needs a new instance id and it needs a new run, one that's essentially like the first run [22:58] I see two separate folders, /var/lib/cloud/sem and /var/lib/cloud/instance/sem. /v/l/c/sem has just one file: config_scripts_per_once.once. /v/l/c/instance/sem has many files, all of the form config_XXX, all of which seem to correspond to stages listed in /etc/cloud/cloud.cfg though I did not check every single one. [23:00] And /v/l/c/instance is indeed symlinked to /v/l/c/instance-very-long-guid, which I read is there in case this happens to a volume or filesystem that began life on one instance but the got started up when attached to a different instance, and so cloud-init can determine if it needs to run again; and there's a flag that controls this behavior in cases where that behavior is not what you want.