| powersj | throwaway5234: your content needs to be indented | 00:04 |
|---|---|---|
| powersj | try running your cloud-config through a yaml validator | 00:04 |
| powersj | like http://www.yamllint.com/ | 00:04 |
| throwaway5234 | Took away a needed ! from the binary line, but that did the job. | 00:31 |
| throwaway5234 | Thanks @rharper @powersj | 00:32 |
| smoser | rharper, powersj if people are asking questions like that... honestly the easiest thing to do is to let yaml.safe_dump do it. | 02:00 |
| smoser | http://paste.ubuntu.com/p/4Tqk9fNnt5/ | 02:00 |
| powersj | smoser: thanks we should add that to rtd for debug | 02:10 |
| smoser | we have lots of "how do i write yaml" questions for sure. | 02:28 |
| * blackboxsw also uses cloud-init devel schema --config-file <your-yaml-file>, which gives you that same error. | 02:28 | |
| blackboxsw | but admitedly that yaml traceback is not awesome for someone to debug | 02:29 |
| smoser | and me has 'yaml-dump' which verifies the yaml and writes it to more obvious json | 02:30 |
| smoser | http://paste.ubuntu.com/p/bKPBF7PNPt/ | 02:30 |
| smoser | i gues though binary data is not part of json | 02:30 |
| smoser | so that would fail. | 02:30 |
| mgerdts | Is there a plan to cut a new release sometime soon? I'm trying to work out a strategy where (non-ubuntu) images that Joyent publishes can contain a custom build of 18.2 (or 18.5 or 18.6) without fear that vendors will release a newer package that doesn't have all of the SmartOS fixes. 18.2 came just before my fixes started rolling in. | 13:37 |
| mgerdts | In parallel, I plan to work with debian/fedora/redhat to get our patches in their official packages. | 13:37 |
| smoser | mgerdts: https://launchpad.net/cloud-init/+milestone/18.3 | 13:42 |
| smoser | https://launchpad.net/cloud-init/+milestone/18.4 | 13:42 |
| smoser | we're on rougly 3 month release cycle | 13:42 |
| mgerdts | excellent, thanks | 13:42 |
| paulmey | good morning all! | 14:53 |
| smoser | hi paul | 14:54 |
| paulmey | smoser: I have made some changes to my MP... | 14:54 |
| paulmey | to get the env variable inside mount_cb, I pulled the update_env from subp to the mount_cb def | 14:55 |
| paulmey | does that sound acceptable? | 14:56 |
| smoser | probalby... i think probalby fine to make 'mount' always use LANG=C also | 14:56 |
| smoser | but your change seems safer from a not break things perspective | 14:56 |
| paulmey | ok, good | 14:57 |
| paulmey | your other remark (don't pass down the whole dsconfig, but just the preserve_ntfs flag) was very straigtforward | 14:58 |
| smoser | that sort of stuff makes testing much easier. | 14:59 |
| smoser | i often times do the same thing as you did (maybe you were following code where i'd done that :) | 14:59 |
| paulmey | alright, I'd call it ready for review then | 15:02 |
| daru | hey can anyone help me, I'm trying to run a script at boot, but it doesn't seem to work, I've added my script in /var/lib/cloud/scripts/per-boot/ but it doesn't seem to work, I just want to run some iptables commands, I was wondering what am I missing, thanks! | 15:23 |
| smoser | daru: executable ? | 15:23 |
| smoser | is the file you've added executable | 15:23 |
| daru | yes | 15:24 |
| smoser | well... that *does* work. i verified it yesterday. | 15:24 |
| smoser | can you run 'cloud-init collect-logs' and put the .tar.gz it creates somehwere ? | 15:25 |
| daru | lemme see | 15:25 |
| daru | is that a command on cloud-init? doesn't seem to exist | 15:27 |
| blackboxsw | that command should exist on cloud-init 17.2 or later | 15:28 |
| daru | Oh, I'm a bit lost, I'm running cloud-init 0.7.9 on a raspbian stretch | 15:31 |
| daru | it looks like hypriot is not in that version yet, thanks anyway! | 15:35 |
| blackboxsw | daru, no worries, you basically need to grab the following files to ease triage http://cloudinit.readthedocs.io/en/latest/topics/capabilities.html#cloud-init-collect-logs | 15:43 |
| daru | oh thanks, that's really helpful, already found cloud init is trying to run it on boot but fails | 15:47 |
| daru | is this helpful? https://paste.ee/p/nFarT#1EGl2BJ5UVLsATnNVmoILgZXSNspWoPn | 15:56 |
| blackboxsw | daru: so /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding has an "exec format error" it may have spewed more useful stderr into /var/log/cloud-init-output.log when run.... you can also try running /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding on the booted instance to see if it emits the failure output that is usefule | 16:00 |
| daru | it runs ok if I run it as root, and the other raspberries start having internet | 16:02 |
| blackboxsw | daru, it makes me think that the content provided in bootcmd is not valid shell. are you running it with 'sudo /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding' ? | 16:07 |
| blackboxsw | or were you running it with sudo bash /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding ? | 16:07 |
| daru | I just did `sudo /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding` and it worked (on the booted instance) | 16:08 |
| daru | and the content is just 3 very simple iptables rules | 16:09 |
| daru | It's probably some silly mistake of mine, but i cannot see it haha | 16:10 |
| smoser | daru: look in /var/log/cloud-init-output.log | 16:17 |
| daru | I've seen it, but I'm not seeing anything useful (I renamed the file btw) | 16:19 |
| daru | 2018-05-18 18:17:12,558 - util.py[WARNING]: Failed running /var/lib/cloud/scripts/per-boot/set_iptables [-] 2018-05-18 18:17:12,573 - cc_scripts_per_boot.py[WARNING]: Failed to run module scripts-per-boot (per-boot in /var/lib/cloud/scripts/per-boot) 2018-05-18 18:17:12,574 - util.py[WARNING]: Running module scripts-per-boot (<module 'cloudinit.config.cc_scripts_per_boot' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_scrip | 16:19 |
| smoser | that woudl be log | 16:19 |
| smoser | we want cloud-init-output.log | 16:19 |
| smoser | which contains the output of the commands it ran | 16:19 |
| daru | I only see that kind of info in /var/log/cloud-init.log, here is https://paste.ee/p/hoLAH#08KAuIZf1l58lU8DD5UFgazCrEmTqTTv | 16:22 |
| blackboxsw | The file /var/log/cloud-init-output.log (contains stdout/stderr from scripts to console) versus /var/log/cloud-init.log which contains running debug messages about cloud-init operations | 16:22 |
| blackboxsw | note the -output | 16:23 |
| smoser | i suspect you do not have a '#!' in taht ? | 16:24 |
| smoser | /var/lib/cloud/scripts/per-boot/set_iptables | 16:24 |
| daru | I have #!/usr/bin/bash | 16:25 |
| smoser | is /usr/bin/bash there ? | 16:25 |
| daru | here are both just in case https://paste.ee/p/47GrL#Ak9Z4hN6hviDUuh3dOOCF1XVOAcR99T6 | 16:25 |
| daru | let me see | 16:25 |
| daru | oh no | 16:26 |
| daru | it's in /bin/bash | 16:26 |
| daru | gonna change and check, ty! | 16:26 |
| daru | yesss, you are the best ppl!! | 16:28 |
| === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 5/28 16:00 UTC | cloud-init 18.2 released (03/28/2018) | quotes: <daru> yesss, you are the best ppl!!! | ||
| blackboxsw | :) thx daru | 16:29 |
| daru | thanks a lot, gonna continue my journey! | 16:29 |
| === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 5/28 16:00 UTC | cloud-init 18.2 released (03/28/2018) | ||
| blackboxsw | robjo: with your noLnxDistro branch: I'm still trying to reconcile that we already have a system_cfg: distro value which will always be exactly what is written to your new /etc/cloud/cloud-init.user.distro in the event that someone provided --distro at build time. The only difference is that cloud-init.user.distro only currently determines what the response from get_linux_distro() returns instead of grabbing info | 19:49 |
| blackboxsw | from /etc/os-release info, whereas system_info:distro: <variant> determines which distro class is used. | 19:49 |
| blackboxsw | something doesn't feel quite right, why do we need runtime get_linux_distro to get overridden by the file /etc/cloud/cloud-init.user.distro ? | 19:50 |
| robjo | blackboxsw: You make the assumption that the user does not change cloud.cfg, which I would say is often not the case | 19:51 |
| blackboxsw | I'm not quite understanding why we need to persist this build time variant to runtime behavior. When I build something for platform/environment X, I expect that that rpm/deb package is configured to run on target platform/environment X. If someone installs it on environment Y, there may be runtime issues I'd expect. | 19:51 |
| robjo | if the user runs setup.py with --distro ubuntu and then puts centos in cloud.cfg things are going to go wrong and there will be no evidence as to why | 19:52 |
| blackboxsw | robjo: if the user changes cloud.cfg to say a different distro, then I'd expect cloud-init runtime to choose cloudinit.distro.<theirchoice> | 19:52 |
| robjo | yes, but the templates that are on the system are for ubuntu in this example and that is in some cases just not going to work | 19:53 |
| blackboxsw | as with your branch's build time decision to build for target suse|rhel|ubuntu. Our static config templates would be created with (suse|rhel|ubuntu) in mind, so if I now install my package on a ubuntu system with suse ntp templates I can expect it to break | 19:53 |
| robjo | smoser: asked for this to be configurable at build time | 19:54 |
| robjo | I am OK without the build time switch | 19:54 |
| robjo | but if we have the build time switch we need evidence of what was chosen | 19:54 |
| robjo | I really don't care either way, I believe I worked within the guidelines provided | 19:55 |
| robjo | I personally would have probably stuck to leaving the detection fully automatic | 19:56 |
| robjo | but again, if the switch is there we need evidence as to what the "builder/installer" selected, or for certain issues we'll be up the creek with no answers and a lot of time wasted | 19:56 |
| blackboxsw | robjo: we have that buildtime switch that is persisted sort of, it results in the original /etc/cloud/cloud.cfg delivered (and the template selections chosen because of our templater going down if variant X paths). Any change the user makes after cloud-init is installed I would say we don't care about. (just like with /etc/network/interfaces files). I feel like that's outside the scope of a build-time flag given. | 19:58 |
| robjo | OK, I will remove the file writing and reserve the right to say "I told you so" at some point in the future ;) | 19:59 |
| blackboxsw | maybe I'm wrong here. but minimally it feels like overriding runtime behavior of get_linux_distro is going to cause us problems, because we have overridden the original build config templates, and some of the runtime system_info() behavior, but the rest of cloud-init modules make assumptions based on a system being whatever distro it claims it is. I'd be worried about fallout. | 19:59 |
| blackboxsw | hehe | 20:00 |
| blackboxsw | robjo: yeah I'll try to get a quick talk with smoser on this to make sure I'm not on my own island of insanity here | 20:00 |
| smoser | if it is configurable via config... and just defaults to "auto" | 20:01 |
| smoser | then i thinkt hat'd be enough. | 20:01 |
| smoser | i would just like for someone to be able to clearly say "this is arch, you silly ubuntu developer." | 20:01 |
| robjo | we have the configuration option and we have the "auto" behavior by default. The question really revolves around whether or not we keep evidence that the "builder/installer" explicitly set the distro, i.e. deviated from default auto behavior | 20:05 |
| robjo | From my perspective, when one allows the user to do something evidence of that action should be collected and stored | 20:05 |
| robjo | which is why I decided to write it to a file | 20:05 |
| robjo | But again, I am not attached to the file, I'll remove to get this thing finally done | 20:06 |
| robjo | smoser: blackboxsw ^^^^ | 20:07 |
| blackboxsw | robjo: I think I'm good with the file in /etc/cloud/ just not the runtime behavior change as a result. the file itself makes it easier to triage why rendered config content was chosen the way it was. So I think we should keep that artifact around | 20:08 |
| blackboxsw | in a meeting on this at the moment robjo to get you an answer today | 20:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!