| blackboxsw | noahm: thank you for raising that to our attention, I'm fixing the doc builds now and regenerating tagged releases | 03:24 |
|---|---|---|
| blackboxsw | I did that early last week I believe, thinking I checked all the boxes on a docs migration to a readthedocs site that didn't have ads embedded. | 03:24 |
| noahm | blackboxsw: thank you! :) | 04:04 |
| blackboxsw | noahm: reverted the migration temporarily so it won't redirect for the moment. most of the old builds fail on new RTD-hosted.com tooling. So, we'll sort how to export or migrate those static old builds before flipping the switch. noahm out of curiousity, how old a version were you interested in | 04:22 |
| * blackboxsw was looking at making sure we sync back to 0.7.9 but not sure if we need to stretch farther | 04:25 | |
| noahm | blackboxsw: I certainly don't anticipate needing anything further back than that. 19.3 is far enough for most of what I'm likely to care about. | 05:36 |
| holmanb | SuperLag: welcome :D | 11:47 |
| holmanb | SuperLag: ln 19 I was invoking cloud-init from a clone of the source code, on a system that has cloud-init installed that could be called as `cloud-init schema -c test.yml`, or using the --system flag instead of -c to check the schema on the system from the datasource rather than from a file. | 11:51 |
| holmanb | SuperLag: https://cloudinit.readthedocs.io/en/latest/reference/cli.html#schema | 11:51 |
| holmanb | SuperLag: https://cloudinit.readthedocs.io/en/latest/reference/faq.html#how-can-i-debug-my-user-data | 11:51 |
| holmanb | SuperLag: and if you want to run ln 19 the way I did (on a system without cloud-init installed) you could `git clone git@github.com:canonical/cloud-init.git && cd cloud-init` before running that command. | 11:55 |
| SuperLag | holmanb: you still around? | 16:46 |
| holmanb | SuperLag: yes | 16:50 |
| SuperLag | I went to the second link. And there's a python script there. Ran it, it says "userdata.yaml - ok". | 16:52 |
| holmanb | SuperLag: ahh the validate-yaml.py one? | 16:53 |
| SuperLag | but when I installed cloud-init on my jump box, and was testing... I did "cloud-init schema -c userdata.yaml" and got --> Error: Cloud config schema errors: users.0: {'default': None} is not valid under any of the given schemas | 16:53 |
| SuperLag | so I'm not sure which one to believe :D | 16:53 |
| SuperLag | holmanb: yep | 16:53 |
| holmanb | don't trust that one | 16:53 |
| holmanb | thanks for pointing that out, the docs need to be updated | 16:53 |
| SuperLag | don't trust that script? or the latter? | 16:53 |
| holmanb | all that validate-yaml.py does is check if your config file is valid yaml | 16:54 |
| SuperLag | which isn't sufficient for it to work with cloud-init, I take it? | 16:54 |
| holmanb | correct, valid yaml doesn't mean it is valid user-data | 16:55 |
| holmanb | do you have a colon after "default" in your users list>? | 16:56 |
| SuperLag | I do. | 16:57 |
| holmanb | SuperLag: if you see the paste from before, you'll note that I deleted the colon in the version of your userdata that passed the validation | 16:57 |
| SuperLag | sure enough :D | 16:57 |
| SuperLag | and after removing that it passes muster :D | 16:58 |
| holmanb | SuperLag: \o/ | 16:58 |
| SuperLag | Is cloud-init supposed to work the same for all distros? or are there differences depending on distro? | 16:59 |
| holmanb | SuperLag: there are many things that cloud-init can't guarantee across distros - package name, for example, varies from distro to distro | 17:00 |
| holmanb | SuperLag: and there are some distros which cloud-init doesn't support | 17:00 |
| holmanb | SuperLag: however, it operates similarly for most distros | 17:02 |
| holmanb | SuperLag: on the modules page you'll note that each module has a "Supported distros" list | 17:03 |
| SuperLag | One of the things I haven't tried yet, is to mark one of the generated VMs as a template, and see if subsequent VMs have the cloud-init stuff baked in. Having the VMware datasource makes life VERY nice. | 17:03 |
| holmanb | SuperLag: Should work, depending on what you mean by that. | 17:07 |
| holmanb | SuperLag: You'll note that Module Frequency for many modules is "once-per-instance", so cloud-init will execute those modules only once per instance (this is customizable in cloud.cfg). | 17:08 |
| andrew76 | Recently I've noticed problematic behavior using cloud-init's "packages" functionality to install some apt packages on Ubuntu 20.04. It seems to install the packages fine, but then if I look after the fact, the packages contain no files at all | 17:52 |
| andrew76 | if I run "dpkg -L <package>", I get "Package '<package>' does not contain any files (!)"; so the apt package is installed, but there are no files associated with it; any suggestions on how to fix this? Thanks! | 17:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!