[00:04] <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:31] <throwaway5234> Took away a needed ! from the binary line, but that did the job.
[00:32] <throwaway5234> Thanks @rharper @powersj
[02:00] <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:10] <powersj> smoser: thanks we should add that to rtd for debug
[02:28] <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:29] <blackboxsw> but admitedly that yaml traceback is not awesome for someone to debug
[02:30] <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.
[13:37] <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:42] <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
[14:53] <paulmey> good morning all!
[14:54] <smoser> hi paul
[14:54] <paulmey> smoser: I have made some changes to my MP...
[14:55] <paulmey> to get the env variable inside mount_cb, I pulled the update_env from subp to the mount_cb def
[14:56] <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:57] <paulmey> ok, good
[14:58] <paulmey> your other remark (don't pass down the whole dsconfig, but just the preserve_ntfs flag) was very straigtforward
[14:59] <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 :)
[15:02] <paulmey> alright, I'd call it ready for review then
[15:23] <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:24] <daru> yes
[15:24] <smoser> well... that *does* work. i verified it yesterday.
[15:25] <smoser> can you run 'cloud-init collect-logs' and put the .tar.gz it creates somehwere ?
[15:25] <daru> lemme see
[15:27] <daru> is that a command on cloud-init? doesn't seem to exist
[15:28] <blackboxsw> that command should exist on cloud-init 17.2 or later
[15:31] <daru> Oh, I'm a bit lost, I'm running cloud-init 0.7.9 on a raspbian stretch
[15:35] <daru> it looks like hypriot is not in that version yet, thanks anyway!
[15:43] <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:47] <daru> oh thanks, that's really helpful, already found cloud init is trying to run it on boot but fails
[15:56] <daru> is this helpful? https://paste.ee/p/nFarT#1EGl2BJ5UVLsATnNVmoILgZXSNspWoPn
[16:00] <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:02] <daru> it runs ok if I run it as root, and the other raspberries start having internet
[16:07] <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:08] <daru> I just did `sudo /var/lib/cloud/scripts/per-boot/set_iptables_for_internet_forwarding` and it worked (on the booted instance)
[16:09] <daru> and the content is just 3 very simple iptables rules
[16:10] <daru> It's probably some silly mistake of mine, but i cannot see it haha
[16:17] <smoser> daru: look in /var/log/cloud-init-output.log
[16:19] <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:22] <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:23] <blackboxsw> note the -output
[16:24] <smoser> i suspect you do not have a '#!' in taht ?
[16:24] <smoser>  /var/lib/cloud/scripts/per-boot/set_iptables
[16:25] <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:26] <daru> oh no
[16:26] <daru> it's in /bin/bash
[16:26] <daru> gonna change and check, ty!
[16:28] <daru> yesss, you are the best ppl!!
=== 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!!!
[16:29] <blackboxsw> :) thx daru
[16:29] <daru> thanks a lot, gonna continue my journey!
=== 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)
[19:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <robjo> I really don't care either way, I believe I worked within the guidelines provided
[19:56] <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:58] <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:59] <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.
[20:00] <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:01] <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:05] <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:06] <robjo> But again, I am not attached to the file, I'll remove to get this thing finally done
[20:07] <robjo> smoser: blackboxsw ^^^^
[20:08] <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:13] <blackboxsw> in a meeting on this at the moment robjo to get you an answer today