[07:53] <nakilon> hello
[07:53] <nakilon> I'm thinking about migrating from Centos to ChromiumOS on GCP
[07:54] <nakilon> I'm reading the https://cloud.google.com/container-optimized-os/docs/how-to/create-configure-instance#advanced but I don't see the answer on the question: How? When the change of the attached metadata  is applied?
[07:54] <nakilon> is it some cloud-init command to be called manually via ssh?
[07:55] <nakilon> by "applied" I mean that the updated section of the config to be ran so it would start some new docker container that I would describe in it
[08:00] <nakilon> the "cloud-init - Building clouds one Linux box at a time (PDF)" link at https://cloudinit.readthedocs.io/en/latest/topics/faq.html seems to be dead
[09:01] <gabuscus> hello! I'm working on updating the puppet cloud-init module; what would be the preferred way of hacking on the python modules? since cloud-init comes preloaded on the cloud images right now I'm manually editing the scripts on the target box and triggering manual runs of the module using the CLI. is there a better way of doing this? thanks!
[14:10] <nakilon> hmmm, the docs here https://cloudinit.readthedocs.io/en/latest/topics/cli.html#init say that 'init' runs 'init' and 'init-local' boot stages; that according the https://cloudinit.readthedocs.io/en/latest/topics/boot.html are respectively Network and Local
[14:13] <nakilon> does it mean that if I want to run 'runcmd' then instead of running 'cloud-init init' like this answer says https://stackoverflow.com/a/50911376/322020 I have to run something like 'cloud-init config'? since according to Boot stages docs the runcmd is in Config?
[14:17] <nakilon> actually it recommends using Final at all, so probably so for example this snippet uses bootcmd https://cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem#mounting_and_formatting_disks this one uses runcmd
[14:17] <nakilon> https://cloud.google.com/container-optimized-os/docs/how-to/run-container-instance#configuring_docker_daemon_to_pull_images_from_registry_cache but if I want to start containers and do similar staff at random points of time I should use some directive to be run in Final? I don't see any in
[14:17] <nakilon> https://cloudinit.readthedocs.io/en/latest/topics/examples.html only bootcmd and runcmd
[14:35] <nakilon> what is the "cloud_final_modules in /etc/cloud/cloud.cfg"? I don't see it in https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[14:41] <rharper> nakilon: /etc/cloud/cloud.cfg is configuring cloud-init itself,  cloud_final_modules are the list of modules that run with cloud-init modules --mode=final is run;  all of the modules are in /usr/lib/python3/dist-packages/cloudinit/config/cc_<module_name>.py ;  the config_XXX_modules defines which and in what order those modules runs corresponding to a certain time in boot that cloud-init runs.
[14:42] <rharper> nakilon: for daemon starts, runcmd is fine, while the runcmd module runs at config stage, it writes out your scripts to be invoked *as late as possible* during boot to allow for package install and other things to be initialized first; 
[14:42] <rharper> so if you included packages: ['docker.io'] runcmd: ['do this cmd thingy with docker'], that should work as the package will be installed before the runcmd script is executed; 
[14:54] <nakilon> oooh I start understanding; so in the /etc/cloud/cloud.cfgI see that there is a place for my commands -- the runcmd; and when I do clound-init clean && cloun-init modules --mode=config it will run only those from this stage that are with 'always', right?
[14:57] <nakilon> or probably if I use 'clean' then I should better use 'init'; or maybe not use 'clean' at all if I don't necessary need it
[15:02] <rharper> nakilon: are you booting an instance on a cloud, if so they accept user-data  text, in which you can include your yaml, runcmd and such.  If you are booting outside of a cloud, you'll want to look at the NoCloud datasource and decide how you plan to include the config (meta-data, user-data) to the system;
[15:03] <rharper> you don't want to modify /etc/cloud/cloud.cfg (this controls cloud-init itself),  you can place user-data in /etc/cloud/cloud.cfg.d/my-config.cfg -- however, that won't run unless you've configured a datasource, https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html 
[15:04] <nakilon> yeah, I'm going to upload a file via gcloud for user-data
[15:06] <nakilon> but I'm not sure if the updated metadata would have any effect without a reboot
[15:06] <nakilon> not sure yet how it works
[15:24] <nakilon> I suppose if I had the user-data set before starting the instance it would be copied to the /etc/cloud/cloud.cfg.d/ directory and there I would be supposed to edit it manually reflecting the changes I do to instance metadata
[15:25] <nakilon> so since there is no file yet I'm supposed to use NoSource and then after the reboot the config will be gone since the /etc directory isn't persistent and it would use the config obtained from metdata instead
[15:26] <nakilon> *it will
[15:42] <rharper> nakilon: right, it won't affect the instance;   
[15:46] <rharper> if you are running in a cloud, you have a few options;  1) if you update the metadata of the instance then you can run cloud-init clean and reboot; this will allow cloud-init to run like it's a new instance, however, depending on what config you provide, they may fail if they cannot handle being run more that once 2)  launch a new instance with your updated user-data instead 
[15:47] <rharper> the user-data isn't copied into the /etc/cloud/cloud.cfg.d directory, rather cloud-init reads the metadata from the cloud's metadata server, you'll see it in /var/lib/cloud/instance/user-data.txt ;
[15:58] <nakilon> if for example I put a bunch of 'docker run ...' to runcmd, boot, they are now running, then I add some new container and want to see if the new added 'docker run' works properly within the config, should I add it to  /var/lib/cloud/instance/user-data.txt to then run the 'cloud-init modules --mode=config'?
[16:00] <nakilon> and what if one of runcmd commands exits with non-zero (for example, failing to run a container because it's already running; or if it's a reboot but some mistake is made) -- will it continue? ir will it stop and not run the rest of the runcmd commands list?
[16:01] <nakilon> *or
[16:02] <rharper> that won't work the way you want;   I think you want to use write_files: to write out an your runcmds to /var/lib/cloud/scripts/per-boot/<my executable script here>  
[16:03] <rharper> cloud-init is meant to do the initial customization for a new instance;  so the user-data is fetched and consumed once, subsequent boots, its basically checking to see if it's running on the same instance or if the image was captured and booted in a new instance;  it's not involved in on-going configuration/customization for the lifecycle of an instance; 
[16:04] <rharper> that said, I think scripts/per-boot  sound like what you want, in that you can update that file and on each boot if this instance, cloud-init will run it;  you do need to design your script with that in mind (you may need to check before you run a command if it's not idempotent) 
[16:06] <nakilon> aha, I see, for my use cases I should look into using some other things related to continuous deployment  rather than cloud-init
[16:29] <rharper> I think so if you're managing a server ; cloud-init does support initial configuration of puppet/chef