[16:21] <holmanb> @minimal: ping
[16:24] <minimal> holmanb: hi
[16:25] <holmanb> minimal: thanks for the fs PR :)
[16:25] <holmanb> minimal: I'm a little confused why the parsing differs between ubuntu and alpine (works on ubuntu). Does alpine have its own cli parser?
[16:25] <minimal> yeah I found it by chance when I found the time to actually test cc_disk_setup/cc_mounts on Alpine
[16:26] <minimal> Alpine is using stock e2fsprogs mkfs.ext4
[16:26] <minimal> and the manpages that I looked at for various mkfs tools all show options before the device name
[16:26] <holmanb> agreed, per the docs what we're doing now doesn't make sense
[16:26] <holmanb> just curious why it works on ubuntu
[16:27] <minimal> the only difference then between Alpine using mkfs.ext4 and Ubuntu using mkfs.ext4 would be musl vs glibc
[16:27] <minimal> so unless mkfs.ext4 is using some libc function that behaves differently on musl vs glibc I don't know
[16:27] <minimal> musl does pride itself in following POSIX spec
[16:28] <holmanb> I wonder if their getopt() implementation differs from glibc
[16:30] <minimal> ah, from https://wiki.musl-libc.org/functional-differences-from-glibc.html
[16:31] <minimal> "GNU getopt permutes argv to pull options to the front, ahead of non-option arguments. musl and the POSIX standard getopt stop processing options at the first non-option argument with no permutation."
[16:31] <holmanb> nice
[16:31] <holmanb> that checks out
[16:31] <holmanb> thanks for finding that :)
[16:31] <minimal> so glibc resorts the cli list internally to "fix up" for badly ordered options?
[16:31] <holmanb> sounds like a glibc thing to do
[16:32] <minimal> yeah a GNU "extension" to POSIX
[16:32] <aciba> I was digging into https://github.com/tytso/e2fsprogs/blob/master/misc/mke2fs.c but you were faster :)
[16:32] <minimal> so glibc helps people who don't follow the manpage lol
[16:32] <minimal> you saw also the minor docs/example changes I put in that PR?
[16:33] <aciba> then we could potentially have more wrong commands over musl
[16:33] <holmanb> either way, the PR lgtm - though for future git history mining purposes I think it would be better to update the proposed commit message  to something like "It is not clear to me how the existing code ever worked *with (musl|non-glibc) based OSes* ..." or something to that affect
[16:33] <holmanb> minimal: I can do that unless you'd prefer to
[16:33] <minimal> holmanb: I can do that now
[16:34] <holmanb> thanks
[16:34] <holmanb> > so glibc helps people who don't follow the manpage lol
[16:34] <holmanb> glibc "helps" with a lot of things ;)
[16:34] <minimal> BTW re disk_setup, it currently is listed as for all distros but it apparently has never been tested with BSD and I'm not sure all the commands it uses are available for BSD
[16:35] <minimal> there' currently no way to define any c-i modules as "linux only"
[16:35] <minimal> short of listing all the various linux distros individually
[16:36] <holmanb> aciba: +1 agreed we should probably check for other commands too
[16:38] <holmanb> minimal: helpers for that would be nice, matrix management for "distro" support has probably outgrown its current interface
[16:40] <minimal> well I was wondering whether in addition to "all" there should be "all-linux" and "all-bsd" definitions
[16:40] <holmanb> sounds reasonable to me
[18:46] <cjp256> holmanb: there's some variants out there, but I'm looking at one that matches https://bugs.launchpad.net/cloud-init/+bug/1844191
[18:46] -ubottu:#cloud-init- Launchpad bug 1844191 in cloud-init "azure advanced networking sometimes triggers duplicate mac detection" [Critical, Fix Released]
[18:47] <cjp256> the fix committed their addresses it most of the time, but there is a gap between when the interface surfaces and gets bonded as the slave interface, so there's a race there still
[18:48] <cjp256> at the end of the day, I think it's simply fair to say that duplicate mac is a bad assertion other than for the data structures being used there :)
[19:49] <holmanb> cjp256: agreed
[20:11] <holmanb> cjp256: net.__init__.py assumes mac addresses on a host are unique in a bunch of different places :(
[21:59] <holmanb> cjp256: I just reopened 1844191. It seems like cloud-init shouldn't be gathering this info yet if the kernel hasn't finished configuring interfaces yet, unless some other attribute is given that we can key off of in place of the `*/master` entry.
[23:13] <cjp256> thanks holmanb