[10:31] Hello, [10:31] I'm working on adding network support to our DataSourceScaleway [10:31] So far, I'm able to get the config written on the first boot, but it gets overwritten by subsequent reboots [10:31] I believe that this is caused by the DEP_NETWORK dependancy [10:32] If I understand correctly, Removing this DEP_NETWORK dependancy means that our DataSource is responsible for bringing up the network, right ? [11:29] caribou: a local datasource is one that can be identified positively by local resources. [11:30] it may declare supply network configuration for the system. [11:33] As I was reading though https://hackmd.io/NUUO4nndS4CXTItl8Rs6Nw?both, I was a bit confused by lines 59 & 70. Should those both start with 'nic'? [11:37] i have to agree with you. i made the change there, but there are other occurences of 'nic', . lets ask rharper when he is in. [11:38] ok, sounds good === hrybacki is now known as hrybacki|mtg [14:02] smoser: mgerdts: yeah, it was nic there; there is a general rough equivalence between nic and network; but specifically hotplug of a NIC (which is really a udev event on kernel subsystem "net") is a rudimentary way of providing an indication to the guest that it should query metadata service for updated configuration; you can imagine that a provide may indicate this in other ways and may want to reconfigure [14:02] "networking" whether or not a NIC has been added or removed [14:03] I'm happy to bikeshed on the schema we want to be more precise [14:35] I can see a fix for LP#1774666 has been merged in to trunk, what's the best way for me to get that on my system? Wait for the next build of the cloud-init-dev/daily PPA? [14:40] yep [14:40] bug #1774666 [14:40] bug 1774666 in netplan.io (Ubuntu Cosmic) "Bond interfaces stuck at 1500 MTU on Bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1774666 [14:47] rharper: Thanks, i'll keep an eye on the PPA [14:51] KingJ: for Bionic, we need to do an SRU; We'll do a new upstream snapshot during the SRU process and the daily ppa https://launchpad.net/~cloud-init-dev/+archive/ubuntu/daily get get the bionic package before the SRU is complete; you can test that out there but once the SRU has been started, the package will also showup in bionic-proposed [14:53] What would the rough timelines be around the SRU / proposed / daily build? (apologies, this is the first time i've been blocked on something where the fix isn't quite out yet, but I appreciate it's not an instantaneous thing!) [14:56] we can get a new upstream snapshot landed possibly today, maybe tomorrow, then the next days ppa will have the package, the SRU takes processing time to verify the changes once it's uploaded to -proposed, and then verification that it resolves the issues and no regressions, then a 7 day wait in -proposed for other testing and general wait before it's copied to -updates [15:03] Great, i'll keep an eye out - thank you for the information :) [15:03] sure === hrybacki|mtg is now known as hrybacki [15:21] rharper: thanks for clearing that up [15:22] smoser: pushed pycodestyle fix to handle utf8 chars in cloud-config branch [15:22] jenkins is testing now https://jenkins.ubuntu.com/server/job/cloud-init-ci/79/ [15:32] just kicked off https://jenkins.ubuntu.com/server/job/cloud-init-integration-ec2-b/24/ which should give us a green now that salt_minion test fixes are in tip [15:45] smoser: how do we 1) add bionic and 2) update devel to cosmic here: https://code.launchpad.net/~cloud-init-dev/+recipes === r-daneel_ is now known as r-daneel [15:53] rharper: responed https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347698 [15:53] powersj: getting that [15:57] powersj: https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel [15:57] bah. [15:57] Distribution series. had 'bionic', not 'cosmic' [15:57] fixing [15:58] ok so that just required selecting a different distro? [16:03] ok fixing this today https://bugs.launchpad.net/cloud-init/+bug/1776701 [16:03] Ubuntu bug 1776701 in cloud-init "ec2: xenial unnecessary openstack datasource probes during discovery" [High,In progress] [16:04] If I understand the workflow correctly, I apply an lxc profile to an ubuntu 18.04 container which influences cloud-init, which in turn influences netplan? I'm just trying to figure out the best way to add a static DNS (ipv6) server [16:04] Does this mean that I will soon be able to not `route add -reject ` before running tests? [16:08] runelind_q: my most common use-case for driving changes in cloud-init though lxc would be 'lxc init ubuntu-daily:bionic myb1; lxc config set user.user-data - < mycloudconfig.yaml; lxc myb1 start;' [16:09] cat > mycloudconfig.yaml < #cloud-config [16:10] looks like some of those values can just be set in the lxc profiles rather than passing another yaml file [16:12] runelind_q probably so. lxc provides cloud-init with the proper-full network config which ends up in /var/lib/cloud/seed/nocloud-net/network-config on the booted container [16:12] cool, I'll take a look there [16:12] lots of abstraction going on :) It's like Inception networking [16:12] lxc also provide vendor_data as distinct from user-data (which both get merged to provide cloud-init customization) [16:13] yeah definitely runelind_q, so when you provide a profile checkout that seed directory to see how lxc mapped it out. cloud-init consumes those to "do the right thing" with netplan [16:13] to do network-config in lxd, you need to specify that separately; you cannot user-data in network-config [16:14] https://github.com/lxc/lxd/blob/master/doc/cloud-init.md [16:14] rharper: can't you define the network-config via the same type of mechanism (right a profiles would allow you to differentate network-config for user.user-data) [16:15] just saw the link, good one [16:15] yeah, it's just like user.user-data but it's a different file/template (network-config) [16:16] ok good deal. So, if using the CLI instead of profiles : lxc init ubuntu-daily:bionic myb1; lxc config set myb1 user.network-config -< mynetwork-v1-or-v2.yaml; lxc start myb1;' [16:17] and that should ultimately show up in /var/lib/cloud/seed/nocloud-net/network-config I would presume [16:17] on the container [16:17] yeah, was going to paste a quick config to add the additional dns entry [16:17] thanks rharper === r-daneel_ is now known as r-daneel [16:21] that said, I don't know if we have a way to append additional DNS entries on an interface using DHCP [16:24] I guess I could also see if containers will listen to DNS servers being advertised via SLAAC [16:24] shouldn't that come via the dhcp option when the client requests a lease? [16:24] this is all ipv6 [16:26] yeah /me was thinking option 23 and option 24 in dhcpv6 :( [16:27] almost there [16:30] stay on target [16:30] =) [16:30] I've got tone [16:31] yeah, not so much for RDNSS [16:33] oh, there it goes. [16:37] https://paste.ubuntu.com/p/9rPcBrGX3x/ [16:38] I don't have dhcp6, so I can't tell, but on my system, it puts the static v6 dns in the list; not sure about priority; this falls into dark magic of networkd/systemd-resolved [16:48] yeah, it doesn't show up is resolv.conf, but v6 DNS works fine ¯\_(ツ)_/¯ [17:05] ok jenkins integration-ec2-b is finally green again. only known cloud-init CI errors remaining are ec2-x (because of openstack warnings) and the -cosmic tests failing because of our ppa [17:05] both in flight [17:15] ok need to sort unit tests, but will be proposing the following as a fix for OpenStack datasource to avoid unneeded metadata probes on ec2 [17:15] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/bug/1776701-openstack-local-no-probe-on-ec2 [17:15] heading to an early lunch. [17:21] blackboxsw: 2 fixes in review-mps pushed [17:22] https://github.com/CanonicalLtd/uss-tableflip/commit/15b5e593c48aba5f24fc921a11385e7fa8f4eb29 [17:22] https://github.com/CanonicalLtd/uss-tableflip/commit/66fb6a5e9df8db41e96a13d6f1d7ce913bd22028 [18:03] runelind_q: sorry, resolv.conf is always going to point to 127.0.0.53 which is systemd-resolved caching nameserver (much like previous resolvconf in Ubuntu Xenial); you can run: networkctl status or systemd-resolved --status and you can see the set of DNS endpoints you've got configured === r-daneel_ is now known as r-daneel [22:10] ok no probe fix is up https://trello.com/c/0s2gnxyX/835-openstacklocal-should-not-probe-metadata-on-ec2 [22:11] now onto joyent/azure hot/cold plug [22:14] powersj: :( looks like integration-c w/ lxd is an issue https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-ec2-c/5/console [22:14] on lxd and ec2 [22:14] yeah noticed that now that we have a daily cosmic deb [22:14] I can take a look tomorrow if you want [22:14] man it's like the red won't go away :/ [22:14] heck of a lot better though [22:15] powersj: yes please, I think I need to finish a strawman for a mtg tomorrow w/ joyent [22:15] and largely due to me switching from building master to using the built daily deb [22:15] yep, I was gonna say, "all powersj fault" [22:15] totally [22:16] PEBPAK (problem exists between Powers and keyboard) [22:16] has nothing to do with code-quality mind you [22:23] ;)