/srv/irclogs.ubuntu.com/2018/06/01/#cloud-init.txt

=== r-daneel_ is now known as r-daneel
blackboxswsmoser: 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:49
rharperok17:50
rharperblackboxsw: what's the expected behavior you're looking for ?17:50
blackboxswI 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 otherwise17:51
rharperyou want journalctl --unit systemd-networkd-wait-online.service17:51
rharperit doesn't say much, but will display which interfaces it is waiting on17:51
rharpernetworkd itself doesn't do the waiting17:51
rharperwait-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
blackboxswok May 31 22:13:12 SRU-worked systemd[1]: Starting Wait for Network to be Configured...17:52
blackboxswMay 31 22:13:12 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo17:52
blackboxswMay 31 22:13:12 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo17:52
blackboxswMay 31 22:13:14 SRU-worked systemd-networkd-wait-online[819]: ignoring: lo17:52
blackboxswMay 31 22:13:14 SRU-worked systemd-networkd-wait-online[819]: managing: eth017:52
blackboxswMay 31 22:13:14 SRU-worked systemd[1]: Started Wait for Network to be Configured.17:52
rharperin 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 eth017:53
rharperthat looks right to me17:53
blackboxswok, there's the specific 'ignoring' comment I was looking for note non-CamelCase Ignoring. I mistook the output logs.17:53
rharperah17:54
rharperyes, that's networkd talking about itself17:54
blackboxswthe issue is that I did  specific an eth1 match by name configuration as optional:false17:54
blackboxswI expected in this case that network online would have blocked here17:54
rharperI'm confused, it blocked17:54
rharperyou should see something like network-oniline.target reached17:55
rharperin journalctl before you see cloud-config.service run17:55
rharper# journalctl -o short-precise | egrep "(Started Wait for Network|Reached target Network is Online|modules:config)"17:57
rharperMay 24 21:46:47.134424 b1 systemd[1]: Started Wait for Network to be Configured.17:57
rharperMay 24 21:46:47.869092 b1 systemd[1]: Reached target Network is Online.17:57
rharperMay 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:57
blackboxswJun 01 17:42:05.526609 SRU-worked systemd[1]: Started Wait for Network to be Configured.17:58
blackboxswJun 01 17:42:07.491945 SRU-worked systemd[1]: Reached target Network is Online.17:58
rharperyes17:58
rharperit's fast17:58
blackboxswon my system a 2 second wait, but I presented an eth1 optional:false device17:58
blackboxswI thought it's wait for a timeout on eth1 which never came up17:58
rharpercan you ssh add me? lp:raharper ?17:59
blackboxswyeah17:59
rharperI'm not sure what you're trying to test17:59
rharpermaybe hangout  too ?17:59
blackboxswyeah hangout and 52.179.192.2518:01
mgerdtssmoser: 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
mgerdtsresync: https://github.com/mgerdts/ubuntu-cloud-init/commit/d9cdb9cce708ec011205f3ef92cd27480523375c18:23
mgerdtsconvert eni, call apply_network(): https://github.com/mgerdts/ubuntu-cloud-init/commit/b901ce58764e7eece41da4a8d425e325a677c5cc18:23
smosermgerdts: fwiw you can push to launchpad18:23
mgerdtsYeah, 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:24
mgerdtsBeing in a different repo than I already have, things are difficult.  I seem to have lost the magic that I had once.18:25
smosermgerdts: here is my ubuntu git repo fwiw18:26
smoser$ git remote -v18:26
smoserpkg https://git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init (fetch)18:26
smoserpkg ssh://smoser@git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init (push)18:26
smosersmoser https://git.launchpad.net/~smoser/ubuntu/+source/cloud-init (fetch)18:27
smosersmoser ssh://smoser@git.launchpad.net/~smoser/ubuntu/+source/cloud-init (push)18:27
smoseryours would not be ssh for the push to 'pkg', but ... s/smoser/mgerdts/ should work18:27
mgerdtsthanks.   Now they are the top two changesets at https://code.launchpad.net/~mgerdts/ubuntu/+source/cloud-init/+git/cloud-init/+ref/trusty-joyent18:30
smosermgerdts: yeah.. so quick glance that looks really good.18:34
smoserand thansk for separating out the configure ENI one18:34
smoserright.18:35
mgerdtsI see that resolv.conf is still not configured, and probably routes18:35
mgerdtsIs 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:37
mgerdtsAnd 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:38
LzrdKinghi, how can i make cloud-init restart rsyslog after it sets the hostname?18:45
smosermgerdts: yeah.. the code there is just so old it doesnt have any of this18:46
LzrdKingi 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 restarted18:47
mgerdtsok, i'll just add the needed bits.18:47
smoserLzrdKing: well it does not do anything if the rsyslog top level key is not there... that module just gets out.18:49
LzrdKingwould just "rsyslog:" in the config file be enough to make it restart?18:50
smoserit might be enough to just do:18:50
smoser rsyslog:18:51
smoser  service_reload_command: "auto"18:51
LzrdKingon 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:52
smoserLzrdKing: maybe not.18:54
smoserbut in /etc/cloud/cloud.cfg.d/LzrdKing.cfg18:54
LzrdKingi don't rsyslogd getting restarted18:58
LzrdKingdon't see*18:58
smoserhttp://paste.ubuntu.com/p/cBt8JncKD7/18:58
smoserLzrdKing: ^ that works here. it also had logic that says "if no configs, then nothing to do".18:59
smoserand acutally you can probably dit the 'servic_relload_command'. just the configs entry is enough probably.18:59
smoserhthat will write the comment to /etc/rsyslog.d/20-cloud-config.conf18:59
smoserand will restart19:00
LzrdKingcould this be why its not running: "helpers.py[DEBUG]: config-rsyslog already ran (freq=once-per-instance)"19:04
LzrdKingbingo19:06
LzrdKingi ran "cloud-init single -n rsyslog --frequency always" and the proper hostname immediately showed up in the logs19:06
LzrdKingnow i wonder if we need the additional lines19:09
LzrdKingwe don't19:10
LzrdKingand /var/lib/cloud/instance/cloud-config.txt seems to be the file it's reading19:13
LzrdKingi need more than just "rsyslog:" though, otherwise i get "cloud-init[WARNING]: Ran rsyslog but it failed!"19:14
LzrdKingsyslog 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 wrong19:17
mgerdtssmoser: 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=d14e34e8496c2f8fc5b3e9bb1115a107b208d0cf21:08
smosermgerdts: i can try to take a more full look on monday.21:09
mgerdtsthanks21:10

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!