| === shardy is now known as shardy_lunch | ||
| === shardy_lunch is now known as shardy | ||
| boxrick | Does cloud init run at first boot only or each and every boot? | 12:05 |
|---|---|---|
| powersj | boxrick: by default it will run at each boot. However, not all parts of cloud-init will run each time. For example, it does not need to generate ssh keys on each boot. | 12:31 |
| boxrick | Ok lovely, cheers for that | 13:29 |
| blackboxsw | rharper: I'm tearing out the cloud-init query subcommand, no need for Notimplemented() subcommands. We can add it in when we have something | 17:38 |
| blackboxsw | as it is right now, you actually get tracebacks because we don't even setup the event stack approporiately (undefinted parameters etc). | 17:39 |
| rharper | blackboxsw: +1 | 17:48 |
| blackboxsw | rharper: I'm having trouble finding where exactly the module runtime is cached (and validated):w is the frequency caching handling in cloud-init ( | 19:22 |
| blackboxsw | oops, typo-world. one sec | 19:22 |
| blackboxsw | having a hard time finding where the cache of module runtimes is stored once a specific module is run... and where that frequency is validated to avoid running the module a 2nd time (for PER_ONCE frequencies) | 19:23 |
| rharper | blackboxsw: when you say module, you mean each cc_<module> ? | 19:23 |
| blackboxsw | rharper: yeah | 19:23 |
| rharper | so, in stages.py I Think you'll see the reporter setup | 19:23 |
| rharper | also, the sem files, I think record some data | 19:24 |
| blackboxsw | ok, yeah I just wasn't really seeing log messages telling me cc_ntp, for instance, is being ignored because it's configured PER_INSTANCE | 19:25 |
| blackboxsw | per "cloud-init --debug single --name cc_ntp" | 19:25 |
| rharper | so, when you run in single mode, not sure how well the logging is configured | 19:31 |
| rharper | if you look at cmd/main.py there's *complicated* logic w.r.t when/how logging is configured/enabled IIRC | 19:32 |
| blackboxsw | ahh I'm seeing the issue now. right logging is incomplete on the single commandline. The appropriate, and needed, messages about skippping due to invalid frequency, or disabled module etc just go into /var/log/cloud-init.log | 19:37 |
| blackboxsw | right we need a stdout handler too if running single from the commandline (we don't want that in init, modules or dhclient-hook subcommand cases I imagine as they are spawned by init or dhcp). | 19:38 |
| blackboxsw | ok and all semaphore logic is in cloudinit/helpers. | 19:41 |
| blackboxsw | ok now I get how that works | 19:41 |
| rharper | yeah | 19:41 |
| TemporalBeing | q: what is the intent with `runcmd`? Should it be possible to have multiple `runcmd` sections in a single cloud-init script and have them *all* run or does only the *last* get run? | 20:26 |
| TemporalBeing | (I've found that `package_update` and `package_upgrade` but `packages` installs stuff just fine. | 20:27 |
| blackboxsw | my understanding is that cloud-init piecies together all cloud-config parts ultimately into a single structure representing all cloud-config parts. So if there are multiple-definitions of the same keys, the latest piece read is what gets honored | 20:29 |
| blackboxsw | so I believe if there are multiple commands that we want to run via runcmd, you'd need to include them in a single runcmd list like the simplistic example https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd | 20:32 |
| rharper | blackboxsw: TemporalBeing: yeah, run_cmd takes a list; package_update and package_upgrade are flags which map to a distros package manager for fetching repository data (package_update on ubuntu/debian does an apt-get update); and package_upgrade does a apt-get upgrade | 20:35 |
| rharper | s/flags/booleans | 20:35 |
| TemporalBeing | @rharper: I haven't gotten package_update/package_upgrade to work, so I have two runcmd sections - one to do what those do, then after the packages are installed via `package` more to do other things, including enabling things from the installed packages. | 20:36 |
| rharper | TemporalBeing: what does your cloud-config look like ? | 20:39 |
| TemporalBeing | @rharper - something like https://gist.github.com/BenjamenMeyer/eaadf44fb6ac187465578cc6d02f59b9 | 20:48 |
| rharper | k | 20:50 |
| rharper | TemporalBeing: looks fine, you can collapse the write-files and run commands together; I found one issue with your pip requriements file, you marked it b64 encoded, but it's just plain txt, so pip didn't like it, http://paste.ubuntu.com/25314461/ | 21:02 |
| rharper | trying that now; you'll be able to ssh in if you add a ssh key, and tail /var/log/cloud-init-output.log to see the apt upgrade/install, etc (output of runcmds end up there) | 21:02 |
| TemporalBeing | yeah, I had to sanitize it - the b64 encoding difference was part of that; the structure is basically the same | 21:02 |
| rharper | ah, gotcha | 21:02 |
| TemporalBeing | my biggest issue is that the first cloud-init data (creating the /root/.config, and pushing a file into it) isn't getting run at all; the rest seems to be working | 21:03 |
| TemporalBeing | can't figure out why, and can't get cloud-init to dump anything useful to diagnose | 21:03 |
| rharper | hrm, let me see | 21:03 |
| TemporalBeing | told if I remove some stuff then reboot I can get cloud-init to reprocess, which has kind of worked | 21:04 |
| TemporalBeing | but no success in diagnostics of what's wrong | 21:04 |
| TemporalBeing | If I need to rewrite to put everything into unique sections, okay...I can manage | 21:04 |
| rharper | so, you don't need to do a mkdir for things with write_Files | 21:05 |
| rharper | cloud-init will ensure the path to the file exists | 21:05 |
| TemporalBeing | it failed if I didn't :( | 21:05 |
| rharper | hrm | 21:06 |
| rharper | TemporalBeing: which cloud-init version ? | 21:07 |
| TemporalBeing | initially on Ubuntu 16.04, now 17.04 | 21:07 |
| rharper | write_files module uses util.write_file in cloud-init, which calls a method ensure_dir() which does a recursive mkdir on the paths needed | 21:07 |
| TemporalBeing | so presently working with ubuntu's version 0.7.9-113-g513e99e0-0ubuntu1~17.04.1 | 21:08 |
| rharper | k | 21:08 |
| * rharper removes the mkdir and tries again | 21:08 | |
| rharper | write_files will happen first, then runcmd, then package-update-upgrade-install | 21:09 |
| rharper | TemporalBeing: hrm, I think runcmd happens too soon here; I'm going to file a bug; as per the docs, it should be running at "rc.local" like time, but | 21:24 |
| TemporalBeing | @rharper thanks for taking a look; refactoring some of my scripts too around the only the last perspective | 21:25 |
| rharper | np, I'll paste the bug here and you can subscribe to it if you like | 21:25 |
| TemporalBeing | sure - thanks | 21:26 |
| TemporalBeing | the `write_files` didn't create the directory :( | 21:28 |
| TemporalBeing | okay...I think I know what happened - I added another `write_files` section and the merge functionality isn't merging that section so only one of the two (the second) gets processed | 21:30 |
| rharper | yes | 21:30 |
| rharper | that's what I mentioned about combining | 21:30 |
| rharper | both runcmd and write_files takes a *list* of entries | 21:30 |
| rharper | if you have two top-level config keys, one of them will get clobbered when the configs are merged | 21:30 |
| TemporalBeing | it *should* have merged them - that's what the merging functionality talks about | 21:30 |
| rharper | it does mention that | 21:31 |
| rharper | list type should append | 21:31 |
| TemporalBeing | http://cloudinit.readthedocs.io/en/latest/topics/merging.html talks about them getting combined together | 21:31 |
| rharper | so we may have a second bug here (possibly fixed in artful) | 21:31 |
| rharper | but not yet in xenial | 21:31 |
| rharper | will need to investigate that | 21:31 |
| TemporalBeing | gotcha | 21:31 |
| blackboxsw | rharper: sorry I wasted a bit of your time on my 2nd review of cloudinit analyze today. I hadn't pushed enough content to you. I've addressed review comments now I think and updated docs. | 21:36 |
| rharper | blackboxsw: no worries; I've implemented a quick summary verb we can use to print a one-line summary of the boot | 21:36 |
| rharper | I'll have a patch/MP for you tomorrow; but it allows a cloud-init analyze (no args) to print that out ala systemd-analyze; then we can do the cloud-init analyze show|blame|dump etc as we do with params and such | 21:37 |
| blackboxsw | bah, just saw your branch up CLI features | 21:38 |
| blackboxsw | https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/328992 | 21:38 |
| blackboxsw | I can rework my commandline.rst topic doc to incorporate your branch/changes | 21:38 |
| rharper | ah, doc update | 21:38 |
| rharper | if you want, that's cool | 21:38 |
| blackboxsw | ok I'll pull it in. as I also touched on that | 21:38 |
| rharper | I just noticed that when reading rtd this morning | 21:38 |
| blackboxsw | sorry it took so long to push it up | 21:39 |
| rharper | np | 21:39 |
| blackboxsw | rharper: question once you have a chance to tox -e doc on my branch. should all of that content be migrated to capabilities.rst? | 21:41 |
| blackboxsw | or should it continue to live some a separate page. | 21:41 |
| blackboxsw | It has a lot of your cloudinit analyze README.md notes etc. | 21:41 |
| blackboxsw | which doesn't feel like it makes sense as the "entry" page of cloudinit capabilities | 21:42 |
| rharper | blackboxsw: lemme see | 21:50 |
| rharper | blackboxsw: so I'd make a new topic for the bulk of that instead of the CLI page; | 21:52 |
| rharper | something like a Boot Time Analysis | 21:52 |
| blackboxsw | Ok and then we just don't talk about cloud-init cmdline | 21:52 |
| blackboxsw | much other than analyze specifically | 21:53 |
| blackboxsw | so where should cloud-init single go? | 21:55 |
| blackboxsw | an ammendment to the modules topic? | 21:55 |
| blackboxsw | cloud-init (modules|init) are both kindof discussed on the stages topic | 21:55 |
| rharper | We may want a general debugging/testing section where we can put both Analyze and single | 21:56 |
| blackboxsw | that sounds good, then I can drop the rest | 21:56 |
| blackboxsw | and it won't collide w/ your branch | 21:56 |
| rharper | we certainly can still have a cli reference section that just has mostly --help like output | 21:56 |
| rharper | my branch is tiny | 21:56 |
| rharper | easily rebased/appended as needed | 21:56 |
| rharper | I wouldn't worry about collision | 21:57 |
| blackboxsw | +1 | 22:00 |
| blackboxsw | thanks | 22:00 |
| blackboxsw | approved https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/328992 | 22:09 |
| blackboxsw | and I pushed my doc changes again | 22:09 |
| blackboxsw | separate debugging/testing doc. dropped discussion of cloud-init (init|modules) as that's kinda covered by stages | 22:10 |
| blackboxsw | gotta run for a few. | 22:10 |
| rharper | later | 22:17 |
| blackboxsw | back | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!