[08:54] <bbabich> Howdy all - A brief question if I may...
[08:54] <bbabich> Updating config of interface linux OSes
[08:55] <bbabich> ie, enabling inet6 auto
[08:55] <bbabich> Is the only way via a runcmd?
[08:55] <bbabich> Anything native that you guys have run into?
[09:00] <bbabich> Hmm
[09:00] <bbabich> http://curtin.readthedocs.io/en/latest/topics/networking.html#subnet-ip
[13:51] <smoser> bbabich, so what you can do is put networking config with that inside
[13:51] <smoser> in the image.
[14:57] <smoser> bbabich, see the 'example config' at https://launchpad.net/ubuntu/+source/curtin/0.1.0~bzr479-0ubuntu1
[14:57] <smoser> bah
[14:57] <smoser> at
[14:57] <smoser> https://gist.github.com/smoser/45935e78bf1b21ee7696be083240aa0f
[14:57] <smoser> but if you do use that, you have to know the name (or mac) of eth0.  the "fallback" config is more dynamic as cloud-init picks what it views as "the first network device".
[15:45] <smoser> utlemming, http://paste.ubuntu.com/24268424/
[15:45] <smoser> rharper, take a read of ^ and let me know if you disagree with the suggestion. i think that is what we agreed to yesterday.
[15:45] <smoser> its not idea.
[15:45] <smoser> ideal
[15:46] <utlemming> smoser, rharper: that will result in the second nameserver overriding the first
[15:47] <rharper> yeah, resolvconf sucks
[15:47] <utlemming> I dug in on resolvconf, and you'll see `dns-nameservers 10.0.0.1` as the final
[15:47] <smoser> well, in that case we'd get both. if you declare all on all.
[15:47] <rharper> yeah, we need to combine dns_* entries from all subnets, and put them in the network_state 'dns_*' fields
[15:48] <utlemming> okay, that's seems simple enough...but it feels icky
[15:48] <smoser> just looking at resolvconf man page it looks like it sort of supports this, but it would expect ENI to run resolvconf with a different IFACE.PROG for each of those stanzas.
[15:48] <rharper> smoser: the issue is resolvconf being called for each iface stanza, and collecting the dns- values and overwriting
[15:49] <rharper> smoser: right, but when the hook runs, IFACE=eth0 for each stanza
[15:49] <rharper> which clobbers subsequent calls
[15:49] <smoser> i could imagine ENI being extended to either let you declare the name to go to resolvconf or consistently create one (as long as it could do the same on takedown)
[15:49] <rharper> the best debugging is to dump the ENV that ifupdown sets when the 00resolvconf ifup hook it is called
[15:50] <rharper> there maybe other information that we could use in the hook (before we call resolvconf -a )
[15:51] <smoser> it looks like it does *sort* of handle it.
[15:51] <smoser> it uses "ADDRFAM"
[15:51] <smoser> so it would seem that one ipv4 and one ipv6 would work
[15:52] <smoser> right ?
[15:52] <utlemming> smoser: that is how I read it
[15:53] <utlemming> I'm wondering though if there is a simplier way, but I don't like it either: install a new parser in /etc/resolvconf/update-libc.d/ that handles it all
[15:58] <utlemming> smoser, rharper: what do you guys think of that approach?
[15:58] <utlemming> if our problem is that resolvconf is being obtuse, adding a hook that renders it right might be the cleanest
[15:59] <utlemming> both DNSMasq and Avahi use hooks to do that
[16:00] <rharper> utlemming: indeed; I've not looked at the hook but something needs to know about the multiple stanzas and indicate that the configs should be merged;  not sure how to handle when it should know it should replace the value vs. append/merge
[16:01] <smoser> well...
[16:01] <smoser> so here is one path.
[16:03] <smoser> i have a stanza like this:
[16:03] <smoser> iface eth0 inet6 dhcp
[16:03] <smoser>    smoser_name eth0_dhcp1
[16:03] <smoser> ifupdown puts 'smoser_name=<value>' into the environment of the hooks
[16:04] <smoser> err...
[16:04] <smoser> IF_SMOSER_NAME='eth0_dhcp1'
[16:05] <smoser> so we can just have resolvconf 'opt in' to honoring some variable to influence its name used in
[16:05] <smoser>  /etc/network/if-{down,up}.d/*resolvconf
[16:05] <rharper> smoser: heh
[16:06] <smoser> not joking.
[16:06] <rharper> in general, I think I'd like resolvconf to do the right thing without something like placeholder_for_resolvconf
[16:06] <smoser> we then, as the oracle rendering ENI just have to put sane names
[16:06] <rharper> which name field does resolvconf look at ?
[16:06] <smoser> resolvconf_name=eth0_addr1
[16:06] <rharper> IFACe
[16:06] <rharper> interesting
[16:06] <smoser> right. currently
[16:07] <smoser> look at /etc/network/if-up.d/000resolvconf
[16:07] <smoser> its fairly obvious
[16:07] <smoser> if we put somnething in there, then it gets into the environment at IF_<keyname>=<value>
[16:08] <utlemming> that's a lot cleaner
[16:09] <rharper> right, but this is a change to the resolvconf ifupdown hooks and requires coordination;
[16:09] <smoser> yes.
[16:09] <smoser> and SRU and such.
[16:09] <rharper> we;ll need to define the IF key we want, document and push to upstream resolvconf
[16:09] <smoser> but ends in something that can at least be made reliable
[16:09] <smoser> while what currently have is not
[16:09] <rharper> I think so, yes
[16:09] <utlemming> do we?
[16:10] <utlemming> add /etc/network/if-up.d/000cloudinit
[16:10] <utlemming> and provide it in the cloud-init sru
[16:10] <smoser> nah. we have to update resolvconf
[16:10] <utlemming> which exports the name of the IFACE
[16:10] <smoser> you dont have to export
[16:10] <smoser> ifupdown does that already
[16:10] <smoser> any "option" in a given stanza
[16:11] <smoser> gets exported as
[16:11] <utlemming> well, change the IFACE to the key that we want to use
[16:11] <rharper> how will we handle upgrades for eni's already rendered without the key ?
[16:11] <smoser>  IF_<option> with value VALUE
[16:12] <smoser> rharper, well, fixing it backwards is one thing. that isn't entirely required
[16:12] <smoser> (fwiw, this is a regression of us dropping the eth0:1
[16:12] <smoser> in eni)
[16:12] <rharper> yes
[16:13] <smoser> which we did to fix anohter bug :)
[16:13] <smoser> bug 1657940
[16:13] <smoser> commit 2de1c247e285cce0b25ab70abdc56ccd41019c27
[16:14] <rharper> indeed, ipv6 bonded bridged vlans and mixed v4 v6 are tons of fun
[16:15] <smoser> i never ceases to amaze me how unstable all of ENI is
[16:15] <rharper> heh, well, eni itself is stable, the ifupdown parsing/hooks are another story
[16:17] <smoser> well, attempting to actually create non-trivial networking
[16:17] <smoser> s/create/utilize/
[16:18] <rharper> bubblegum and string
[17:03] <paulmey> good morning
[17:03] <paulmey> I'm improving the udev rules in the Azure Linux agent (https://github.com/Azure/WALinuxAgent/pull/624)
[17:04] <paulmey> cloud-init has a similar set of udev rules that link the disks under /dev/disks/cloud/azure-*
[17:06] <paulmey> I'm happy to update that, but I've gotten some feedback that it might be nice to 'unify' both so that the disks are in the same path, no matter if the distro uses only the agent or only cloud-init or a combination of both
[17:07] <paulmey> It would make Azure Linux documentation a lot more straightforward with regards to this point
[17:07] <paulmey> Thoughts?
[17:15] <smoser> rharper, utlemming https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/321203
[17:15] <smoser> thats what i thikn that would look like
[17:15] <smoser> i dont like 'prog'
[17:15] <smoser> but that is what resolvconf calls that.
[17:19] <smoser> paulmey, i'm not sure what you're asking.
[17:30] <utlemming> smoser: that sane to me
[17:37] <rharper> smoser: resolvconf changes look good
[17:40] <smoser> i NACK'd my own review
[17:40] <smoser> :)
[17:40] <smoser> should rename those things and document
[17:40] <smoser> i'd like someone on foundations to have a think also
[17:41] <smoser> utlemming, i think most of those "dangerous" comments in the debian wiki are probably garbage
[17:41] <smoser> i suspect its no less dangerous (== broken) than any other ifupdown method
[17:41] <utlemming> probably
[17:42] <utlemming> I'll remove 'em
[17:44] <rharper> I think the most user-facing issue is muscle memory /docs on use of ifconfig;  however, the brave new world of iproute2 eventually needs to be embraced
[17:55] <utlemming> smoser: I'll get a MP to you this afternoon to implement this in CI later today
[17:58] <paulmey> smoser, sorry about that
[17:58] <paulmey> currently, cloud-init create udev links /dev/disk/cloud/azure-*
[17:59] <paulmey> the Azure linux agent creates links /dev/disk/azure/*
[17:59] <paulmey> currently, both create only links for the root and ephemeral resource disk
[18:00] <paulmey> my PR for the agent adds data disks (extra attached disks)
[18:00] <paulmey> with links like /dev/disk/azure/datadisks/lun9-part1
[18:01] <paulmey> (Azure only lets you specify the LUN on which a disk is attached, hence the usefulness of these links)
[18:02] <paulmey> The question I'm asking is whether we would like the azure agent and cloud-init to create links in the same location
[18:02] <paulmey> so that we can have simple documentation of where to easily identify data disks
[18:40] <smoser> rharper, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1675185
[18:40] <rharper> y
[18:40] <smoser> would it be acceptable to just do : if no 'apt', then just do nothing ?
[18:41] <rharper> not by default, no ?
[18:41] <rharper> my reading of the code was that apt_configure renders the template by default...
[18:41] <smoser> rharper, renders the  apt template
[18:41] <smoser> right?
[18:41] <smoser> apt sources.list
[18:41] <smoser> ah.
[18:41] <smoser> i meant
[18:42] <smoser> if not util.which('apt'):
[18:42] <rharper> oh
[18:42] <smoser>    LOG.debug("Nothing to do")
[18:42] <smoser>     return True
[18:42] <rharper> yeah, that works too, as long as you do it before calling lsb_release
[18:42] <rharper> too
[18:43] <smoser> i cant think of a reason that you'd want cloud-init to configure apt if you didnt have apt in its path.
[18:43] <rharper> it kinda feels like the distro object could check that (apt available) and drop any of the apt/dpkg related config stages
[18:43] <rharper> smoser: agreed
[18:43] <smoser> debconf selections
[18:43] <smoser> is there too
[18:43] <rharper> util.which('dpkg')
[18:43] <rharper> would be helpful filter too
[18:46] <smoser> i'll see what i can do around that.
[18:46] <rharper> cool, thanks
[19:12] <smoser> rharper, dpkg is installed in snappy. as well as debconf-set-selections
[19:12] <rharper> hrm
[19:12] <smoser> so.. something else.
[19:12] <rharper> uc16 has dpkg ?
[19:13] <rharper> I wonder why when they purge the database
[19:13] <rharper> debconf-set-selections also seems like an oversight if they purge the db
[19:13] <rharper> =(
[19:14] <rharper> you can test for /var/lib/dpkg
[19:14] <rharper> raharper@uc16-c2:~$ test -e /var/lib/dpkg; echo $?
[19:14] <rharper> 1
[19:14] <rharper> but that's not nice
[19:14] <rharper> and apt is present
[19:14] <rharper> but it's warning wrapper
[19:15] <rharper> raharper@uc16-c2:~$ which apt
[19:15] <rharper> /usr/local/bin/apt
[19:15] <rharper> raharper@uc16-c2:~$ cat `which apt`
[19:15] <rharper> #!/bin/sh
[19:15] <rharper> echo "Ubuntu Core does not use apt-get, see 'snap --help'!"
[19:17] <smoser> hm..
[19:18] <smoser> i just ran a lxc image
[19:18] <smoser> lxc launch images:ubuntu-core/16 uc16-1
[19:18] <smoser> $ lxc exec uc16-1 -- which apt-get || echo none
[19:18] <smoser> none
[19:28] <rharper> hrm
[19:28] <rharper> this is in my UC16 image i built but I'm not adding those in
[19:28] <rharper> I;ll boot the release image on cdimage next
[19:29] <rharper> http://cdimage.ubuntu.com/ubuntu-core/16/stable/ubuntu-core-16-amd64.img.xz
[19:32] <rharper> smoser: you can 'snap download --stable core'; sudo unsquashfs core*.snap; ls -al squash-rootfs/usr/local/bin/apt
[19:32] <rharper> I'm not sure what snap is in your lxc though
[19:34] <smoser> http://paste.ubuntu.com/24269663/
[19:34] <smoser> what pain
[19:52] <rharper> why is that different?
[19:55] <rharper> the latest "stable" has core version 16-2, rev 1441; which is the same as what's in 'snap download --stable core'
[19:57] <rharper> smoser: I think you want images:ubuntu-core/16/amd64
[20:02] <smoser> rharper, what did i get then ?
[20:02] <rharper> not sure, what's the csum on the lxc image ?
[20:03] <rharper> I'm still downloading that one at 161kb/s
[20:03] <rharper> images remote says it should be c4962bd2e706, and dated 20170318_19:01
[20:03] <rharper> I forget what lxd magic they do
[20:04] <rharper> but clearly what you loaded is really old
[20:06] <powersj> when I tried the lxd core16 images last Friday they seemed very old as well, even using -edge and -beta
[20:13] <smoser> :-(
[20:13] <rharper> I asked in #lxd
[20:13] <rharper> and thanks to my vpn, I'm getting the uk mirror
[20:14] <smoser> ah. i just asked in #lxc-dev
[20:15] <smoser> well that stinnks.
[20:15]  * rharper hopes it finishes before I have to unplug and relocate
[20:15] <smoser> i just assumed that would be a very useful way to use it.
[20:15] <rharper> Retrieving image: 88% (147.33kB/s)
[20:16] <rharper> try snap refresh core
[20:16] <rharper> it should download the latest core snap
[20:16] <rharper> then you can reboot
[20:16] <rharper> for profit
[20:16] <smoser> downloading at 10+M/s
[20:16] <smoser> :)
[20:17] <rharper> rub it in
[20:17] <rharper> vpn needs more speed
[20:17] <smoser> http://paste.ubuntu.com/24269896/
[20:17] <rharper> y
[20:17] <rharper> now check apt
[20:17] <smoser> i have the button clicked that says "use vpn only for vpn traffic"
[20:17] <rharper> I do to
[20:18] <smoser> hm.
[20:18] <rharper> but the dns hijack
[20:18] <rharper> is how they check
[20:18] <smoser> still have dpkg
[20:18] <smoser> dont kjnow why
[20:18] <smoser> oh.
[20:18] <smoser> then i get by due to a proxy
[20:18] <smoser> i have lxd set to proxy
[20:19] <rharper> bbiab
[20:20] <smoser> i'll try to check in later, but i'm probably afk when you do
[20:30] <smoser> while i think it does make sense to not use apt if no apt-get or apt installed, i dont know that that iwll work. i think just disable that thingon is-snappy
[20:35] <rharper> smoser: so, looks like we'll need to deal with the older release w.r.t apt check
[20:36] <rharper> smoser: /var/lib/dpkg is missing in the release and the updated core snap
[20:38] <smoser> well, rpbably not
[20:38] <smoser> as cloud-init will never be installed into an old version
[20:38] <rharper> smoser: it may be reasonable to just allow it to be disabled via config; http://paste.ubuntu.com/24269987/
[20:38] <rharper> cloud-init is most definitly installed
[20:38] <rharper> just disabled by default (/etc/cloud/cloud-init.disabled)
[20:39] <rharper> someone could possible not want to use that config module and not want to modify the stage module list in /etc/cloud/cloud.cfg
[20:39] <rharper> I've also thought about implementing a config stage filter so one could say dont-run-the-following-modules: apt-pipieline, apt-configure, etc
[20:40] <smoser> right.
[20:40] <smoser> i dont want to do disable via config without a generic
[20:40] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/321218
[20:40] <smoser> i have to run now. but that should work, right?
[20:41] <smoser> (note that apply_debconf_selections is inert by default)
[20:41] <rharper> that's foing to fail
[20:41] <rharper> pkgs_installed = util.get_installed_packages(target)
[20:41] <rharper> that's in apply_debconf_selections
[20:41] <rharper> we've no apt
[20:41] <smoser> it only does that if you gave it ifo
[20:42] <smoser>     selsets = cfg.get('debconf_selections')
[20:42] <smoser>     if not selsets:
[20:42] <smoser>         LOG.debug("debconf_selections was not set in config")
[20:42] <smoser>         return
[20:42] <smoser> i've got to go.
[20:42] <smoser> later.