| dojordan | @smoser, gentle bump on my PR. I believe I've addressed all of your comments | 01:29 |
|---|---|---|
| smoser | dojordan: ok. | 13:51 |
| smoser | powersj: t2.micro cost 0.0116/60-minutes | 16:05 |
| smoser | i suspect that our average api-start -> terminate is probably < 10 minutes . | 16:05 |
| powersj | agreed | 16:06 |
| smoser | so each test would end up costing us in *instance-time* ~ 0.001 | 16:07 |
| smoser | still have other charges (possibly network and ebs volume time, but ... cheap) | 16:08 |
| smoser | blackboxsw: i left a question for you at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/335108 | 17:55 |
| blackboxsw | smoser: checking now | 17:59 |
| blackboxsw | smoser: so by dropping silentish downgrading from oauth to non-oauth.... you mean just fail and fail loudly? | 18:01 |
| blackboxsw | that's a fair and explicit behavior | 18:01 |
| sushant | hi guys, i work for Microsoft azure-networking and wanted to discuss the possibility of adding a networking module specific to azure. | 19:01 |
| sushant | This is to support networking scenarios for VMs in Azure. To begin with, it will listen for media disconnect/connect and issue re-DHCP. | 19:02 |
| sushant | This will help us in moving virtual machines from one azure virtual network to another. | 19:03 |
| sushant | Over time, we plan to add support for more advance networking scenarios in azure. | 19:03 |
| sushant | Please let me know if this channel is the best place to discuss, or I can also start an email thread (let me know who should I include in the email). | 19:04 |
| blackboxsw | sushant: saw your comments on dojordan's branch and figured we would probably start a discussion at some point. While the initial discussion can start here. I think it best to email to cloud-init@lists.launchpad.net so that other viewers can participate if needed. | 19:11 |
| blackboxsw | I think initially something to be aware of is the systemd changes for ubuntu releases > Xenial which might make driving dhcp rediscovery a bit tougher | 19:12 |
| blackboxsw | s/tougher/different | 19:12 |
| blackboxsw | sushant: also there is a mechanism in cloudinit now to quickly (and temporarily) interact with dhcp if needed without writing any system lease files or producing artifacts via /sbin/dhcp-script. So you might be able to interact with dhcp if you need to discover new service endpoints etc. | 19:18 |
| blackboxsw | cloudinit/net/dhcp.py:maybe_perform_dhcp_discovery() is something we added to assist in dhcp interactions | 19:19 |
| blackboxsw | but even that helper will have to be adapted in a systemd-only work which doesn't contain a packaged 'dhclient' utility | 19:20 |
| dojordan | @blackboxsw, I looked at that yesterday, but I wanted to confirm on xenial the current solution using bounce will work | 19:20 |
| blackboxsw | s/systemd-only work/systemd-only world/ | 19:20 |
| dojordan | with systemd-networkd we may have another solution using link state disconnect and connect (think unplugging and re plugging the ethernet cable) | 19:21 |
| dojordan | that solution doesn't work on xenial as the networking stack doesn't retrigger DHCP for some reason. we are currently testing on 17.10 but wanted to check in the PR for xenial in the mean time | 19:21 |
| blackboxsw | dojordan: yes I believe for Xenial-only the bounce will continue to work. it's just newer series where this bounce will fallover. | 19:22 |
| blackboxsw | on xenial I believe your are correct that the bounce is required as systemd isn't driving re-dhcp on hostname changes... I *think* | 19:22 |
| dojordan | that is the behavior we saw | 19:23 |
| * blackboxsw has to relook at the changes I just landed related to bounce ifup/down being absent . to re-remember what's going on there | 19:23 | |
| blackboxsw | In artful and bionic ifupdown package is no longer installed in default | 19:23 |
| blackboxsw | cloud images. As such, Azure can't use those tools to bounce the network | 19:23 |
| blackboxsw | informing DDNS about hostname changes. This doesn't affect DDNS updates | 19:23 |
| blackboxsw | though because systemd-networkd is now watching hostname deltas and with | 19:23 |
| blackboxsw | default behavior to SendHostname=True over dhcp for all hostname updates | 19:23 |
| blackboxsw | which publishes DDNS for us. | 19:23 |
| blackboxsw | sorry commit related to this was b05b9972d20ec3ea699d1691b67314d04e852d2f | 19:24 |
| blackboxsw | so, yeah calls to perform_hostname_bounce on xenial will continue to use the ifdown ifup logic to talk to dhcp again | 19:25 |
| blackboxsw | as ifupdown deb package will continue to be delivered in xenial images | 19:26 |
| dojordan | yup, that's the plan | 19:26 |
| dojordan | thanks for confirming | 19:26 |
| blackboxsw | ok; I feel okay about that as we won't break backward compat in xenial and remove ifupdown pkg | 19:26 |
| blackboxsw | and even if you continued to call perform_hostname_bounce on artful, bionic, C-series etc. it'll just no-op and log a warning message | 19:27 |
| blackboxsw | not even warning... a debug message: Skipping network bounce: ifupdown utils aren't present | 19:27 |
| blackboxsw | so if systemd-networkd doesn't do what you want sushant or dojordan's network module will have to do the lifting you mention to make that happen | 19:28 |
| dojordan | exactly. but for xenail we are safe | 19:28 |
| blackboxsw | I believe that is true. /me re-reads any of smoser's concerns there to see if I missed something | 19:28 |
| smoser | dojordan: i was just reading | 19:29 |
| smoser | blackboxsw: but will bounce do *anything* on bionic ? | 19:29 |
| blackboxsw | smoser, not it no-ops and adds a debug message "Skipping network bounce: ifupdown utils aren't present." | 19:30 |
| blackboxsw | s/not/nope/ | 19:30 |
| blackboxsw | cloudinit/sources/DataSourceAzure.py:616-ish | 19:31 |
| blackboxsw | in that case, we blindly rely on systemd-networkd to do it's job and automatically updated dhcp every hostname change | 19:32 |
| blackboxsw | which admitedly is a configurable default behavior which *could* be turned off on custom images | 19:32 |
| dojordan | from what I read the only way to retrigger dhcp if the hostname flag isn't set is to restart systemd-networkd, which is less than idea | 19:34 |
| dojordan | ideal* | 19:34 |
| blackboxsw | unrelated minor comment on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/335108 for you Scott. I'll give this a test on our MAAS to watch it save time :) | 19:36 |
| blackboxsw | +1 dojordan yeah, not sure about the other fallouts of restarting systemd-networkd..... it feels like it begs an api/interface/knob from systemd to make that possible/simple if needed, but I don't have a lot of faith in that feature showing up. | 19:37 |
| smoser | hmm | 19:39 |
| smoser | blackboxsw: http://paste.ubuntu.com/26354996/ ? | 19:41 |
| blackboxsw | +1 smoser | 19:41 |
| sushant | @blackboxsw Thanks a lot, I will start an email thread with cloud-init@lists.launchpad.net | 19:47 |
| blackboxsw | can't remember smoser do we know yet whether bionic cloud-images might drop 'dhclient'? | 19:51 |
| blackboxsw | it's currently still in bionic daily images per my lxc spin ups | 19:51 |
| smoser | they cant easily at themoment | 19:53 |
| smoser | the thing protecting them is initramfs-tools and ubuntu-minimal | 19:54 |
| smoser | http://paste.ubuntu.com/26355073/ | 19:55 |
| dojordan | doesn't systemd-networkd have it's own dhcp client? | 20:04 |
| smoser | dojordan: yes it does. | 20:05 |
| dojordan | so is dhclient sticking around as a no-op? | 20:05 |
| smoser | well, at the moment yes. | 20:11 |
| smoser | its possible that foundations team would change initramfs-tools dependency on it. | 20:11 |
| smoser | and i suspect tha'd allow them to drop it from 'minimal' | 20:12 |
| smoser | cloud-init does use it at the moment on ec2. | 20:12 |
| smoser | i kind of suspect that it willlive in bionic unless someone goes pushing on it. | 20:13 |
| smoser | blackboxsw: somwhat related to above | 20:19 |
| smoser | bug 1739516 | 20:19 |
| ubot5 | bug 1739516 in cloud-init "networking comes up before hostname is set" [Medium,Confirmed] https://launchpad.net/bugs/1739516 | 20:19 |
| smoser | mwhudson says that nothign he found re-dhcp's on hostname change. | 20:20 |
| blackboxsw | hrm..... though it's documented here. https://www.freedesktop.org/software/systemd/man/systemd.network.html#SendHostname= | 20:26 |
| blackboxsw | and I see logic in systemd-229:src/network/networkd-dhcp4.c which calls sd_dhcp_client_set_hostname if link->network->dhcp_send_hostname | 20:30 |
| blackboxsw | ahh but that looks to be just on dhcp4_configure | 20:31 |
| blackboxsw | hmm wonder where/when that's triggered | 20:31 |
| blackboxsw | as you mentioned earlier, might have just been lease expiration etc. | 20:31 |
| smoser | dojordan: i just hit 'submit' on a review. | 20:47 |
| smoser | dojordan: do you know the lease time that azure responds with ? | 20:47 |
| smoser | blackboxsw: did you verify that my maas thing works in a real maas ? | 21:02 |
| smoser | deploy, upgrade, reboot ? | 21:02 |
| smoser | and if so, can you let me into one ? | 21:03 |
| * smoser looks for creds he knows he has | 21:03 | |
| blackboxsw | smoser: I still see tracebacks on artful. but, unrelated to your maas branch. looking deeper | 21:20 |
| blackboxsw | found a bug in cloud-init status just now too. | 21:20 |
| dojordan | @smoser, our leases are 2^32 - 1 seconds... | 21:21 |
| smoser | dojordan: wow! | 21:22 |
| blackboxsw | "('apt-configure', ValueError('Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list',))" | 21:25 |
| blackboxsw | the full traceback | 21:25 |
| blackboxsw | https://pastebin.ubuntu.com/26355603/ | 21:25 |
| blackboxsw | this was maas 2.3 with master + your change . I think master is doing the same thing. | 21:26 |
| blackboxsw | our maas provides an empty ntp: cloud-config | 21:29 |
| blackboxsw | n/n empty pools: [] and servers: [<maas-ip>] | 21:29 |
| blackboxsw | in vendor-data | 21:29 |
| blackboxsw | and I don't see much else as far as apt config | 21:30 |
| dojordan | @smoser, We are exploring an alternate solution to bounce the nic from hyper-v, but in the mean time we would like to get this checked in. So an alternate solution for bionic would be to simply change the hostname. This way, systemd-networkd will keep re triggering DHCP. Once we get the final ovf_env.xml from IMDS, we will actually apply the real, customer provided hostname. If you guys are okay with this approach I will code | 21:32 |
| blackboxsw | smoser: oops missed you creds request | 21:48 |
| blackboxsw | adding | 21:48 |
| blackboxsw | ssh ubuntu@10.5.1.18 | 21:49 |
| blackboxsw | seeing the restored from cache messages as expected due to check_instance_id() returning True | 22:00 |
| blackboxsw | ok that apt error I got was a duplicate of https://bugs.launchpad.net/maas/+bug/1735950 | 22:34 |
| ubot5 | Launchpad bug 1735950 in MAAS 2.3 "ValueError: Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list" [Critical,Triaged] | 22:34 |
| blackboxsw | ok added comments/pastes to that bug, it's targetted to 2.3 and 2.4, so we'll see | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!