=== meetingology` is now known as meetingology
=== philroche_ is now known as philroche
=== vrubiolo1 is now known as vrubiolo
=== vrubiolo1 is now known as vrubiolo
[14:39] <rharper> falcojr: w.r.t v2 -> v1  and ipv6;  I agree that since netplan/systemd-networkd combine several modes under dhcp6: yes ; there isn't enough information to know which one for v1 to use;  I'm not entirely sure what to do about that.
[14:47] <falcojr> ok, thanks. Just wanted to make sure I wasn't missing something
[14:48] <ajmyyra> couldn't find a way to make SLAAC-configured addresses working there, but the specific bug raised was incorrect.
[14:48] <rharper> falcojr: I suspect we may need a discussion with #netplan folks, in particular around whether the yaml format can indicate the different modes to NetworkManager (the other backend)
[14:48] <rharper> SLAAC just works with accept-ra: dhcp6: false IIRC
[14:49] <ajmyyra> yup. but if you wish to discover DNS and routes from DHCP after that, it's a different mode.
[14:49] <rharper> dhcp6: true
[14:50] <ajmyyra> that leads to stateful DHCPv6, doesn't it?
[14:50] <rharper> networkd's dhcp6 client behaves differently than isc-dhcp  is how I understand it
[14:50] <rharper> that is you can bring up your SLAAC whether you're got a response from dhcp6 or not
[14:51] <falcojr> rharper: you're talking about netplan on it's own, right? ajmyyra: You're talking about the translation to v1?
[14:51] <falcojr> I think you're talking about different things
[14:51] <ajmyyra> oh :)
[14:52] <rharper> it's messy since dhcp6 in v2 with networkd backend means you use systemd-networkd's dhcp6 client
=== hjensas is now known as hjensas|afk
[14:52] <rharper> bah, brb
[14:53] <falcojr> I think rharper is explaining why this works for netplan with so few options, but even though it works there, we still have the problem that we can't fully render ENI with these limited options
[14:54] <falcojr> so ajmyyra, I think I'll take back what I said in the initial UpCloud PR, and go ahead with the v1 config :)
[14:54] <falcojr> apologies for the back and forth
[14:54] <ajmyyra> yup. changing it in v2 -> v1 conversion might break existing functionality.
[14:54] <ajmyyra> no probs. sorry for all the hassle as well :)
[14:54] <rharper> falcojr: right ... and where I was headed was that I'm not sure that the NetworkManager backend would know how to configure ipv6 modes without more expressive yaml in netplan
[14:56] <rharper> I've not played with NM backend at all, but if it doesn't have a way to express the various modes via netplan yaml (and I really don't think we do with just accept-ra and dhcp6 *boolean*;  then we should raise that and see what to do;  upstream network had discussions about how the dhcp6 might be something other than boolean;  and whether or not systemd-networkd does; it provides hints at what netplan yaml could do to help expose
[14:56] <rharper> a way to provide user-intent w.r.t ipv6 configurations
[14:59] <Odd_Bloke> As background, cloud-init's v2 YAML format is defined by netplan and on netplan systems, we pass v2 config straight through to netplan. That's why we need to involve them even when we aren't talking about a netplan system: we can't modify that configuration specification and still expect our "forked" configuration to apply successfully (and accurately) on netplan systems.
[15:01] <Odd_Bloke> And I believe Ryan's point is that as netplan supports NM as a first class backend, if we can demonstrate that netplan's configuration language isn't sufficient to configure this with NetworkManager, that's an easier sell than it not being able to express something which none of its backends do.
[15:01] <rharper> Odd_Bloke: +1
[15:34] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/794 is the PR which will merge upstream/20.4.1 into `master`.
[15:36] <Odd_Bloke> blackboxsw: falcojr: ^ FYI
[15:37] <blackboxsw> Odd_Bloke: looking now
[15:39] <blackboxsw> Odd_Bloke: your diff shows more files delta than mine https://github.com/canonical/cloud-init/pull/794/files
[15:39] <blackboxsw> I expected just version.py and Changelog
[15:40] <blackboxsw> here's the diff I got locally https://paste.ubuntu.com/p/B9ptBzYfv2/
[15:44] <Odd_Bloke> blackboxsw: Right, GH is displaying a weird diff.
[15:44] <blackboxsw> ok yeah because I expected we already had that revert in master
[15:46] <Odd_Bloke> `git d $(git merge-base upstream/master upstream/20.4.1) upstream/20.4.1` gives me that same diff, so I assume they're doing something along those lines.
[15:46] <Odd_Bloke> (`d = diff` in my git aliases.)
[15:47] <blackboxsw> Odd_Bloke: approved given that caveat that the github rendering of that diff is "confused" +1 on your analysis there. I think that's exactly right
[15:51] <Odd_Bloke> OK, that's landed; I'll cut an upstream snapshot to hirsute, so we don't have an older version there than in stable releases.
[15:53] <blackboxsw> +1 ping me and I get a quick review on that
[15:55] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/795
[15:55] <Odd_Bloke> blackboxsw: Note the modification in the description.
[15:59] <blackboxsw> Odd_Bloke: one thought (since we've documented the release.py commits in the past
[16:00] <blackboxsw> do we want to include - Release 20.4.1 in place of that redacted Merger upstream changelog entry?
[16:02] <blackboxsw> man I really have to stop logging in a github Ubuntu bot for these reviews
=== bswinnerton1 is now known as bswinnerton
=== ijohnson is now known as ijohnson|lunch
[18:08] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/795 comment addressed
[18:13] <blackboxsw> Odd_Bloke: approved https://github.com/canonical/cloud-init/pull/795/files
[18:13] <blackboxsw> will let you merge /upload
[18:15] <Odd_Bloke> Thanks!
=== ijohnson|lunch is now known as ijohnson
[22:03] <hggdh> the issue I raised the other day (cloud-init hangs on boot on mounting NFS) is bug 1913354
[22:03] <ubot5> bug 1913354 in cloud-init "NFS mounts in /etc/fstab and cloud-init may cause boot hang" [Undecided,New] https://launchpad.net/bugs/1913354
[22:04] <hggdh> since this is affecting a series of customers at Azure... could someone have a look at it?
[22:25] <blackboxsw> hggdh: will get some eyes on it today thx
[23:00] <Odd_Bloke> blackboxsw: falcojr: https://github.com/canonical/pycloudlib/issues/112 <-- thoughts appreciated!
[23:07] <minimal> hggdh: statd is for v2/v3 NFS only (been reading up on various NFS daemon the past day for other reasons). So if you're using V4 only then you could disable it
[23:08] <hggdh> minimal: they are running NFS V3 :-(
[23:10] <hggdh> blackboxsw: thank you. I can get PG involved if you prefer, as well
[23:11] <hggdh> huh. "PG" is Product Group", our internal "upstream"
[23:14] <minimal> hggdh: doh! Guess it wouldn't typically show up on AWS using EFS (for example) as its NFSv4 only AFAIK
[23:21] <hggdh> :-) in this case, the CX I was working on was running the NFS server on Windows, anyways