[17:49] <blackboxsw> smoser: rharper ok I really need eyes on this for a moment http://paste.ubuntu.com/p/Zxtt4ZTm33/ lines 10-20. I'm wondering if that's why networking-online isn't blocked.
[17:50] <rharper> ok
[17:50] <rharper> blackboxsw: what's the expected behavior you're looking for ?
[17:51] <blackboxsw> I enabled debug logs.... I was expecting to see that my yaml files were observed/honored (by wait-for-online) but the log message seem to indicate otherwise
[17:51] <rharper> you want journalctl --unit systemd-networkd-wait-online.service
[17:51] <rharper> it doesn't say much, but will display which interfaces it is waiting on
[17:51] <rharper> networkd itself doesn't do the waiting
[17:52] <rharper> wait-online itself does not look at any of the yaml files, it only talks to networkd itself over dbus to ask it, which interfaces are "managed"
[17:52] <blackboxsw> ok May 31 22:13:12 SRU-worked systemd[1]: Starting Wait for Network to be Configured...
[17:52] <blackboxsw> May 31 22:13:12 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo
[17:52] <blackboxsw> May 31 22:13:12 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo
[17:52] <blackboxsw> May 31 22:13:14 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo
[17:52] <blackboxsw> May 31 22:13:14 SRU-worked systemd-networkd-wait-online[819]: managing: eth0
[17:52] <blackboxsw> May 31 22:13:14 SRU-worked systemd[1]: Started Wait for Network to be Configured.
[17:53] <rharper> in our case, we should see that eth0 is managed by networkd, your debug log shows that it is, and you should see that wait online is waiting for eth0
[17:53] <rharper> that looks right to me
[17:53] <blackboxsw> ok, there's the specific 'ignoring' comment I was looking for note non-CamelCase Ignoring. I mistook the output logs.
[17:54] <rharper> ah
[17:54] <rharper> yes, that's networkd talking about itself
[17:54] <blackboxsw> the issue is that I did  specific an eth1 match by name configuration as optional:false
[17:54] <blackboxsw> I expected in this case that network online would have blocked here
[17:54] <rharper> I'm confused, it blocked
[17:55] <rharper> you should see something like network-oniline.target reached
[17:55] <rharper> in journalctl before you see cloud-config.service run
[17:57] <rharper> # journalctl -o short-precise | egrep "(Started Wait for Network|Reached target Network is Online|modules:config)"
[17:57] <rharper> May 24 21:46:47.134424 b1 systemd[1]: Started Wait for Network to be Configured.
[17:57] <rharper> May 24 21:46:47.869092 b1 systemd[1]: Reached target Network is Online.
[17:57] <rharper> May 24 21:46:48.741229 b1 cloud-init[189]: Cloud-init v. 18.2 running 'modules:config' at Thu, 24 May 2018 21:46:48 +0000. Up 6.00 seconds.
[17:58] <blackboxsw> Jun 01 17:42:05.526609 SRU-worked systemd[1]: Started Wait for Network to be Configured.
[17:58] <blackboxsw> Jun 01 17:42:07.491945 SRU-worked systemd[1]: Reached target Network is Online.
[17:58] <rharper> yes
[17:58] <rharper> it's fast
[17:58] <blackboxsw> on my system a 2 second wait, but I presented an eth1 optional:false device
[17:58] <blackboxsw> I thought it's wait for a timeout on eth1 which never came up
[17:59] <rharper> can you ssh add me? lp:raharper ?
[17:59] <blackboxsw> yeah
[17:59] <rharper> I'm not sure what you're trying to test
[17:59] <rharper> maybe hangout  too ?
[18:01] <blackboxsw> yeah hangout and 52.179.192.25
[18:23] <mgerdts> smoser: I finally have some success.  It's been a long road, and I feel like I maybe am on the wrong path.  I have two patches.  The first does a resync mostly by copy as you suggested.  After that I realized that all calls to apply_network() were done in each datasource and that SmartOS didn't have that at the point that I started from.  So then I needed to write an ENI converter.  See what I mean by wrong path?
[18:23] <mgerdts> resync: https://github.com/mgerdts/ubuntu-cloud-init/commit/d9cdb9cce708ec011205f3ef92cd27480523375c
[18:23] <mgerdts> convert eni, call apply_network(): https://github.com/mgerdts/ubuntu-cloud-init/commit/b901ce58764e7eece41da4a8d425e325a677c5cc
[18:23] <smoser> mgerdts: fwiw you can push to launchpad
[18:24] <mgerdts> Yeah, I tried, searched, tried, and decided that getting this in front of you before the end of your day was more important than sorting out launchpad.
[18:25] <mgerdts> Being in a different repo than I already have, things are difficult.  I seem to have lost the magic that I had once.
[18:26] <smoser> mgerdts: here is my ubuntu git repo fwiw
[18:26] <smoser> $ git remote -v
[18:26] <smoser> pkg https://git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init (fetch)
[18:26] <smoser> pkg ssh://smoser@git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init (push)
[18:27] <smoser> smoser https://git.launchpad.net/~smoser/ubuntu/+source/cloud-init (fetch)
[18:27] <smoser> smoser ssh://smoser@git.launchpad.net/~smoser/ubuntu/+source/cloud-init (push)
[18:27] <smoser> yours would not be ssh for the push to 'pkg', but ... s/smoser/mgerdts/ should work
[18:30] <mgerdts> thanks.   Now they are the top two changesets at https://code.launchpad.net/~mgerdts/ubuntu/+source/cloud-init/+git/cloud-init/+ref/trusty-joyent
[18:34] <smoser> mgerdts: yeah.. so quick glance that looks really good.
[18:34] <smoser> and thansk for separating out the configure ENI one
[18:35] <smoser> right.
[18:35] <mgerdts> I see that resolv.conf is still not configured, and probably routes
[18:37] <mgerdts> Is all of this stuff that I need to be handling in DataSourceSmartOS?  It seems as though it should be handled in generic code.  But maybe I'm spoiled by working on code that is 4 years newer.
[18:38] <mgerdts> And the fact that it's changing the network configuration on get_data() is cringeworthy.  But that seems consistent with the other datasources of that vintage.
[18:45] <LzrdKing> hi, how can i make cloud-init restart rsyslog after it sets the hostname?
[18:46] <smoser> mgerdts: yeah.. the code there is just so old it doesnt have any of this
[18:47] <LzrdKing> i have read http://cloudinit.readthedocs.io/en/latest/topics/modules.html#rsyslog and it says service_reload_command is auto by default but its not being restarted
[18:47] <mgerdts> ok, i'll just add the needed bits.
[18:49] <smoser> LzrdKing: well it does not do anything if the rsyslog top level key is not there... that module just gets out.
[18:50] <LzrdKing> would just "rsyslog:" in the config file be enough to make it restart?
[18:50] <smoser> it might be enough to just do:
[18:51] <smoser>  rsyslog:
[18:51] <smoser>   service_reload_command: "auto"
[18:52] <LzrdKing> on a running instance, i could put that in /var/lib/cloud/instance/cloud-config.txt and then run "cloud-init single -n rsyslog" to test?
[18:54] <smoser> LzrdKing: maybe not.
[18:54] <smoser> but in /etc/cloud/cloud.cfg.d/LzrdKing.cfg
[18:58] <LzrdKing> i don't rsyslogd getting restarted
[18:58] <LzrdKing> don't see*
[18:58] <smoser> http://paste.ubuntu.com/p/cBt8JncKD7/
[18:59] <smoser> LzrdKing: ^ that works here. it also had logic that says "if no configs, then nothing to do".
[18:59] <smoser> and acutally you can probably dit the 'servic_relload_command'. just the configs entry is enough probably.
[18:59] <smoser> hthat will write the comment to /etc/rsyslog.d/20-cloud-config.conf
[19:00] <smoser> and will restart
[19:04] <LzrdKing> could this be why its not running: "helpers.py[DEBUG]: config-rsyslog already ran (freq=once-per-instance)"
[19:06] <LzrdKing> bingo
[19:06] <LzrdKing> i ran "cloud-init single -n rsyslog --frequency always" and the proper hostname immediately showed up in the logs
[19:09] <LzrdKing> now i wonder if we need the additional lines
[19:10] <LzrdKing> we don't
[19:13] <LzrdKing> and /var/lib/cloud/instance/cloud-config.txt seems to be the file it's reading
[19:14] <LzrdKing> i need more than just "rsyslog:" though, otherwise i get "cloud-init[WARNING]: Ran rsyslog but it failed!"
[19:17] <LzrdKing> syslog complains about "service_reload_command" being in /etc/rsyslog.d/20-cloud-config.conf though, not a big deal, much less annoying than the hostname being wrong
[21:08] <mgerdts> smoser: looks like updating eni to configure routes and dns is not so bad.  I updated the eni patch: https://git.launchpad.net/~mgerdts/ubuntu/+source/cloud-init/commit/?id=d14e34e8496c2f8fc5b3e9bb1115a107b208d0cf
[21:09] <smoser> mgerdts: i can try to take a more full look on monday.
[21:10] <mgerdts> thanks