On Fri, Aug 28, 2020 at 4:32 PM Bean Taxi <beant...@gmail.com> wrote:
> I think I've found at least a partial answer to this ... not sure, but I
> suspect the /v/l/c/scripts/per-* folders are used by the cc_script_per_*
> modules, and the /v/l/c/iinstance/scripts folder is used by the
> scripts-user module.
>
Yes, that's correct.
>
> Actually, from looking at the code, I'm 99.9% sure this is what's
> happening. And that there won't be any conflict, they're just independent
> modules.
>
No, the various modules will call run-parts (8) on the directory. The are
called on the frequency of the name.
> On Fri, Aug 28, 2020 at 3:30 PM Bean Taxi <beant...@gmail.com> wrote:
>
>> Hello all,
>>
>> From the handler/shell_script.py code, and from experience & thanks to
>> this list, MIME encoded shellscripts get copied to
>> /var/lib/cloud/instance/scripts.
>>
>> def __init__(self, paths, **_kwargs):
>> handlers.Handler.__init__(self, PER_ALWAYS)
>> self.script_dir = paths.get_ipath_cur('scripts')
>> if 'script_path' in _kwargs:
>> self.script_dir = paths.get_ipath_cur(_kwargs['script_path'])
>>
>> After spending quite a bit of time trying to find where the proper per-*
>> subfolder gets created, I finally realized that it doesn't:
>> /var/lib/cloud/instance/scripts is a flat folder.
>>
> That makes me wonder how cloud-init knows how often to run those scripts,
>> but maybe that's what the scripts-user module is for, particularly the
>> 'Always' tactic.
>>
>
This handler is configured to ensure that it always writes out the script
payload (*not*) how often the script is run.
(crispyboi) cloud-init % lxc exec f4 -- ls -al
/var/lib/cloud/instance/scripts/script.sh
-rwx------ 1 root root 30 Aug 31 15:35
/var/lib/cloud/instance/scripts/script.sh
(crispyboi) cloud-init % lxc exec f4 -- rm
/var/lib/cloud/instance/scripts/script.sh
(crispyboi) cloud-init % lxc exec f4 -- ls -al
/var/lib/cloud/instance/scripts/script.sh
ls: cannot access '/var/lib/cloud/instance/scripts/script.sh': No such file
or directory
..:(╯°□°)╯彡┻━━┻
(crispyboi) cloud-init % lxc exec f4 -- reboot
(crispyboi) cloud-init % lxc exec f4 -- cloud-init status --wait
status: done
(crispyboi) cloud-init % lxc exec f4 -- ls -al
/var/lib/cloud/instance/scripts/script.sh
-rwx------ 1 root root 30 Aug 31 15:36
/var/lib/cloud/instance/scripts/script.sh
Next, for frequency of script execution, the instance shell-script runner,
is cloudinit/config/cc_scripts_user.py which has a frequency of PER_INSTANCE
This module will invoke run-parts on /var/lib/cloud/instance/scripts once
per instance; cloud-init tracks this in the /var/lib/cloud/instance/sem
directory.
>> I'm not sure what the relationship is between /var/lib/cloud/instance/scripts
>> and /var/lib/cloud/scripts/per-*. I have used write_files to write
>> scripts to the per-* folders directly from a cloud_config.yaml, as per a
>> suggestion on #cloud-init, and that indeed works. But I'm not sure how the
>> two script folders might conflict with each other.
>>
>
There isn't a conflict in the directories, but they are used differently
and the contents are provided from different sources typically. The
instance path scripts did is populated only by user-data provided to the
instance. If you capture your instance (save a disk snapshot) and then
launch a new instance with different user-data, then there will be a new
instance directory with different contents. The
/var/lib/cloud/scripts/per-* remain and will run at the correct frequency
independent of the user-data provided to an instance. So if you were to
write script into /var/lib/cloud/scripts/per-instance; it would run once
per instance; and if such an instance's user-data provided a script, both
would one once-per instance.
>> My ultimate goal is to write a very simple custom part handler, for a
>> type I'm calling x-shellscript-per-boot, which saves to
>> /var/lib/cloud/scripts/per-boot. And I'd like to do this so that I can
>> deploy a per-instance script and a per-boot script in the same MIME config.
>> which ultimately is my requirement. And I'm a little concerned I'll be
>> mixing methods.
>>
>
You want to use a cloud-boothook, which is exactly a once-per-boot
shell-script.
>> Thanks!
>> Bean
>>
>>
>> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to : cloud-init@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~cloud-init
> More help : https://help.launchpad.net/ListHelp
>
--
Mailing list: https://launchpad.net/~cloud-init
Post to : cloud-init@lists.launchpad.net
Unsubscribe : https://launchpad.net/~cloud-init
More help : https://help.launchpad.net/ListHelp
