[10:31] <caribou> Hello,
[10:31] <caribou> I'm working on adding network support to our DataSourceScaleway
[10:31] <caribou> So far, I'm able to get the config written on the first boot, but it gets overwritten by subsequent reboots
[10:31] <caribou> I believe that this is caused by the DEP_NETWORK dependancy
[10:32] <caribou> If I understand correctly, Removing this DEP_NETWORK dependancy means that our DataSource is responsible for bringing up the network, right ?
[11:29] <smoser> caribou: a local datasource is one that can be identified positively by local resources.
[11:30] <smoser> it may declare supply network configuration for the system.
[11:33] <mgerdts> 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] <smoser> 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] <mgerdts> ok, sounds good
[14:02] <rharper> 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] <rharper> "networking" whether or not a NIC has been added or removed
[14:03] <rharper> I'm happy to bikeshed on the schema we want to be more precise
[14:35] <KingJ> 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] <rharper> yep
[14:40] <rharper> bug #1774666
[14:40] <ubot5`> bug 1774666 in netplan.io (Ubuntu Cosmic) "Bond interfaces stuck at 1500 MTU on Bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1774666
[14:47] <KingJ> rharper: Thanks, i'll keep an eye on the PPA
[14:51] <rharper> 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] <KingJ> 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] <rharper> 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] <KingJ> Great, i'll keep an eye out - thank you for the information :)
[15:03] <rharper> sure
[15:21] <mgerdts> rharper: thanks for clearing that up
[15:22] <blackboxsw> smoser: pushed pycodestyle fix to handle utf8 chars in cloud-config branch
[15:22] <blackboxsw> jenkins is testing now https://jenkins.ubuntu.com/server/job/cloud-init-ci/79/
[15:32] <blackboxsw> 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] <powersj> smoser: how do we 1) add bionic and 2) update devel to cosmic here: https://code.launchpad.net/~cloud-init-dev/+recipes
[15:53] <smoser> rharper: responed https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347698
[15:53] <smoser> powersj: getting that
[15:57] <smoser> powersj: https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel
[15:57] <smoser> bah.
[15:57] <smoser> Distribution series. had 'bionic', not 'cosmic'
[15:57] <smoser> fixing
[15:58] <powersj> ok so that just required selecting a different distro?
[16:03] <blackboxsw> ok fixing this today https://bugs.launchpad.net/cloud-init/+bug/1776701
[16:03] <ubot5`> Ubuntu bug 1776701 in cloud-init "ec2: xenial unnecessary openstack datasource probes during discovery" [High,In progress]
[16:04] <runelind_q> 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] <mgerdts> Does this mean that I will soon be able to not `route add -reject <link-local-address>` before running tests?
[16:08] <blackboxsw> 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] <blackboxsw> cat > mycloudconfig.yaml <<EOF
[16:09] <blackboxsw> #cloud-config
[16:10] <runelind_q> looks like some of those values can just be set in the lxc profiles rather than passing another yaml file
[16:12] <blackboxsw> 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] <runelind_q> cool, I'll take a look there
[16:12] <runelind_q> lots of abstraction going on :)  It's like Inception networking
[16:12] <blackboxsw> lxc also provide vendor_data as distinct from user-data (which both get merged to provide cloud-init customization)
[16:13] <blackboxsw> 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] <rharper> to do network-config in lxd, you need to specify that separately; you cannot user-data in network-config
[16:14] <rharper>  https://github.com/lxc/lxd/blob/master/doc/cloud-init.md
[16:14] <blackboxsw> 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] <blackboxsw> just saw the link, good one
[16:15] <rharper> yeah, it's just like user.user-data but it's a different file/template (network-config)
[16:16] <blackboxsw> 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] <blackboxsw> and that should ultimately show up in /var/lib/cloud/seed/nocloud-net/network-config I would presume
[16:17] <blackboxsw> on the container
[16:17] <rharper> yeah, was going to paste a quick  config to add the additional dns entry
[16:17] <blackboxsw> thanks rharper
[16:21] <rharper> that said, I don't know if we have a way to append additional DNS entries on an interface using DHCP
[16:24] <runelind_q> I guess I could also see if containers will listen to DNS servers being advertised via SLAAC
[16:24] <blackboxsw> shouldn't that come via the dhcp option when the client requests a lease?
[16:24] <runelind_q> this is all ipv6
[16:26] <blackboxsw> yeah /me was thinking option 23 and option 24 in dhcpv6 :(
[16:27] <rharper> almost there
[16:30] <runelind_q> stay on target
[16:30] <rharper> =)
[16:30] <rharper> I've got tone
[16:31] <runelind_q> yeah, not so much for RDNSS
[16:33] <runelind_q> oh, there it goes.
[16:37] <rharper>  https://paste.ubuntu.com/p/9rPcBrGX3x/
[16:38] <rharper> 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] <runelind_q> yeah, it doesn't show up is resolv.conf, but v6 DNS works fine ¯\_(ツ)_/¯
[17:05] <blackboxsw> 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] <blackboxsw> both in flight
[17:15] <blackboxsw> 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] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/bug/1776701-openstack-local-no-probe-on-ec2
[17:15] <blackboxsw> heading to an early lunch.
[17:21] <smoser> blackboxsw: 2 fixes in review-mps pushed
[17:22] <smoser> https://github.com/CanonicalLtd/uss-tableflip/commit/15b5e593c48aba5f24fc921a11385e7fa8f4eb29
[17:22] <smoser> https://github.com/CanonicalLtd/uss-tableflip/commit/66fb6a5e9df8db41e96a13d6f1d7ce913bd22028
[18:03] <rharper> 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
[22:10] <blackboxsw> ok no probe fix is up https://trello.com/c/0s2gnxyX/835-openstacklocal-should-not-probe-metadata-on-ec2
[22:11] <blackboxsw> now onto joyent/azure hot/cold plug
[22:14] <blackboxsw> 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] <blackboxsw> on lxd and ec2
[22:14] <powersj> yeah noticed that now that we have a daily cosmic deb
[22:14] <powersj> I can take a look tomorrow if you want
[22:14] <blackboxsw> man it's like the red won't go away :/
[22:14] <powersj> heck of a lot better though
[22:15] <blackboxsw> powersj: yes please, I think I need to finish a strawman for a mtg tomorrow w/ joyent
[22:15] <powersj> and largely due to me switching from building master to using the built daily deb
[22:15] <blackboxsw> yep, I was gonna say, "all powersj fault"
[22:15] <powersj> totally
[22:16] <blackboxsw> PEBPAK  (problem exists between Powers and keyboard)
[22:16] <blackboxsw> has nothing to do with code-quality mind you
[22:23] <powersj> ;)