=== r-daneel_ is now known as r-daneel | ||
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:49 |
---|---|---|
rharper | ok | 17:50 |
rharper | blackboxsw: what's the expected behavior you're looking for ? | 17:50 |
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:51 |
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:52 |
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:53 |
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:54 |
rharper | you should see something like network-oniline.target reached | 17:55 |
rharper | in journalctl before you see cloud-config.service run | 17:55 |
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:57 |
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:58 |
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 ? | 17:59 |
blackboxsw | yeah hangout and 52.179.192.25 | 18:01 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:30 |
smoser | mgerdts: yeah.. so quick glance that looks really good. | 18:34 |
smoser | and thansk for separating out the configure ENI one | 18:34 |
smoser | right. | 18:35 |
mgerdts | I see that resolv.conf is still not configured, and probably routes | 18:35 |
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:37 |
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:38 |
LzrdKing | hi, how can i make cloud-init restart rsyslog after it sets the hostname? | 18:45 |
smoser | mgerdts: yeah.. the code there is just so old it doesnt have any of this | 18:46 |
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:47 |
smoser | LzrdKing: well it does not do anything if the rsyslog top level key is not there... that module just gets out. | 18:49 |
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:50 |
smoser | rsyslog: | 18:51 |
smoser | service_reload_command: "auto" | 18:51 |
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:52 |
smoser | LzrdKing: maybe not. | 18:54 |
smoser | but in /etc/cloud/cloud.cfg.d/LzrdKing.cfg | 18:54 |
LzrdKing | i don't rsyslogd getting restarted | 18:58 |
LzrdKing | don't see* | 18:58 |
smoser | http://paste.ubuntu.com/p/cBt8JncKD7/ | 18:58 |
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 | 18:59 |
smoser | and will restart | 19:00 |
LzrdKing | could this be why its not running: "helpers.py[DEBUG]: config-rsyslog already ran (freq=once-per-instance)" | 19:04 |
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:06 |
LzrdKing | now i wonder if we need the additional lines | 19:09 |
LzrdKing | we don't | 19:10 |
LzrdKing | and /var/lib/cloud/instance/cloud-config.txt seems to be the file it's reading | 19:13 |
LzrdKing | i need more than just "rsyslog:" though, otherwise i get "cloud-init[WARNING]: Ran rsyslog but it failed!" | 19:14 |
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 | 19:17 |
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:08 |
smoser | mgerdts: i can try to take a more full look on monday. | 21:09 |
mgerdts | thanks | 21:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!