| nakilon | hello | 07:53 |
|---|---|---|
| nakilon | I'm thinking about migrating from Centos to ChromiumOS on GCP | 07:53 |
| 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:54 |
| 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 | 07:55 |
| 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 | 08:00 |
| 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! | 09:01 |
| 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:10 |
| 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:13 |
| 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:17 |
| 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:35 |
| 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:41 |
| 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:42 |
| 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:54 |
| 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 | 14:57 |
| 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:02 |
| 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:03 |
| nakilon | yeah, I'm going to upload a file via gcloud for user-data | 15:04 |
| 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:06 |
| 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:24 |
| 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:25 |
| nakilon | *it will | 15:26 |
| rharper | nakilon: right, it won't affect the instance; | 15:42 |
| 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:46 |
| 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:47 |
| 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'? | 15:58 |
| 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:00 |
| nakilon | *or | 16:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| rharper | I think so if you're managing a server ; cloud-init does support initial configuration of puppet/chef | 16:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!