=== masber is now known as masuberu
[16:44] <blackboxsw> meh 2FA on hangout
[16:44] <blackboxsw> smoser: I'll try the manual ovf test from our docs and validate whether we can see regression for this SRU
[16:46] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1737704 and  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1731868 are the two cases I wanted to cover
[16:46] <ubot5`> Ubuntu bug 1737704 in cloud-init (Ubuntu) "Cloud-init fails if iso9660 filesystem on non-cdrom path in 20171211 image." [High,Fix released]
[16:46] <ubot5`> Ubuntu bug 1731868 in cloud-init (Ubuntu) "cloud-id: enable ESXi 6.5.0" [High,Fix released]
[16:46]  * blackboxsw grabs a coffee
[16:53] <smoser> blackboxsw: thank you
[18:39] <blackboxsw> hrm, puppet in general doesn't seem to work on bionic
[18:39] <blackboxsw> can't even use the cmdline tooling for documentation
[18:39] <blackboxsw> root@b1:~# puppet --help
[18:39] <blackboxsw> /usr/lib/x86_64-linux-gnu/ruby/2.3.0/openssl.so: symbol SSLv2_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference - /usr/lib/x86_64-linux-gnu/ruby/2.3.0/openssl.so
[18:39] <blackboxsw> root@b1:~# echo $?
[18:39] <blackboxsw> 1
[18:40] <blackboxsw> I'll file a bug against puppet packaging in bionic. but I don't think it'll block the branch that's up for review
[18:40] <blackboxsw> .. though maybe it should
[18:41] <blackboxsw> as we can't currently install a functional ubuntu-packaged puppet for bionic. get a  traceback on Command: ['service', 'puppet', 'start'].
[18:43] <blackboxsw> but I think that looks like ssl-related issues with my example config. I'll validate that before holding up the branch
=== r-daneel_ is now known as r-daneel
[18:55] <rharper> blackboxsw: you can ask in #ubuntu-devel  nacc or others may already know what's up there
[18:55] <blackboxsw> rharper: confirmed PEBKAC. But puppet itself may be brittle.
[18:55] <rharper> hehe
[18:55] <blackboxsw> I think I had an SSL config issue w/ puppet config I specified
[18:56] <rharper> yeah
[18:56] <blackboxsw> but, the puppet commandline falls over and doesn't even let you read it's own man/help info if misconfigured
[18:56] <blackboxsw> trying to confirm that now, and will file an upstream puppet issue if that's the case
[18:59] <nacc> blackboxsw: rharper: did you figure it out?
[18:59] <blackboxsw> nacc: I think I had a stale bionic container and was getting ruby ssl errors (not providing SSL_V_1_0_0 or some such dependency issue.
[18:59] <blackboxsw> nacc: I can't reproduce on fresh bionic containers
[19:00] <blackboxsw> if I can reproduce, I will (I had blown away my stale lxc to see if I could reproduce on something new, but no dice)
[19:00] <nacc> blackboxsw: ack
[19:01] <nacc> blackboxsw: to be clear, puppet has dep8 tests that do test the cli
[19:18] <blackboxsw> thanks nacc. I'm not sure how I got my old container misconfigured. I shouldn't have removed it. I do think I had either a version mismatch in ruby ssl dependencies that prevented puppet's tooling from running. But, using the same puppet configs on my new instances work just fine.
[19:18] <nacc> blackboxsw: it's possible you got bit by a bionic transition?
[19:18] <nacc> blackboxsw: there was an ssl one recently
[19:20] <blackboxsw> I'll chalk it up to that as tracebacks were complaining about missing const definition for SSL_V1
[19:35] <blackboxsw> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/339373 approved
[19:41] <smoser> blackboxsw: thanks.
[19:43] <brunobronosky> Any idea why my attempt to init chef isn't working? http://termbin.com/3kyu
[19:48] <smoser> brunobronosky: cloud-init think the world is fine it looks like
[19:48] <smoser> cat /run/cloud-init/result.json
[19:49] <smoser> maybe chef has some output ?
[19:49] <smoser> systemctl status chef ?
[19:51] <brunobronosky> It's odd to me that chef got installed, but not from the source I requested (taken straight from the cloud-init docs example). And this:
[19:51] <brunobronosky> 2018-02-26 19:16:55,045 - cc_chef.py[DEBUG]: Skipping unknown chef template key 'run_list'
[19:53] <brunobronosky> cat /run/cloud-init/result.json | tb > http://termbin.com/8bto
[19:53] <blackboxsw> brunobronosky: those skip messages are ok..  (though noisy) it just means those key values aren't interpreted but the chef template generator I think. Trying to see aobut your sources comment
[19:54] <blackboxsw> I'm re-reading tip cc_chef module code right now to refresh
[19:55] <blackboxsw> brunobronosky: did you see a /etc/chef/firstboot.json on your system?
[19:56] <brunobronosky> userdata file: http://termbin.com/57yw
[19:56] <blackboxsw> I'd expect that firstboot.json to contain ypour run_list
[19:57] <brunobronosky> Oooo. it does contain my runlist.
[19:57] <blackboxsw> yeah those Skip messages, are noisy and confusing.... I think they should be dropped as the code specifically knows it
[19:57] <blackboxsw> should ignore/skip them
[20:01] <blackboxsw> ok so I see per your cloud-init.log that chef was installed via apt command, which is what your config specified I think.
[20:03] <blackboxsw> brunobronosky: oops
[20:03] <blackboxsw> http://termbin.com/57yw
[20:04] <blackboxsw> ok looks like our doc may have a typo
[20:04] <blackboxsw> I think the apt configuration is wrong
[20:04] <smoser> yeah
[20:04] <smoser> missing sources
[20:04] <blackboxsw> apt:\bsource1: source1:
[20:04] <blackboxsw> apt:\bsources: source1:
[20:04] <blackboxsw> geez typo city
[20:04] <blackboxsw> pasting
[20:04] <smoser> apt/sources/source1:
[20:04] <smoser> rather than
[20:04] <smoser> apt/source1/
[20:05] <blackboxsw> https://pastebin.ubuntu.com/p/RyKqPQQcN8/
[20:05] <blackboxsw> yeah
[20:05] <blackboxsw> that key is bogus.
[20:05] <brunobronosky> aha!
[20:05] <blackboxsw> pultting up a trivial
[20:09] <blackboxsw> brunobronosky: smoser https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/339715
[20:14] <blackboxsw> thanks for raising the question brunobronosky
[21:07] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/339720 rharper or smoser if you get a chance. here's the set hostname approach which I've validated on vsphere. It fixes the DHCP request containing the stock cloud-image hostname 'ubuntu'. I hadn't added the init_main unit test to get coverage on the set_hostname call, but I wanted to bounce the idea off you guys before I sink  time into
[21:07] <blackboxsw> the init-loca CLI unit test.
[21:07] <rharper> k