=== gschanuel7 is now known as gschanuel
=== gschanuel5 is now known as gschanuel
=== gschanuel9 is now known as gschanuel
=== gschanuel9 is now known as gschanuel
=== gschanuel3 is now known as gschanuel
=== gschanuel0 is now known as gschanuel
[02:59] <blackboxsw> Guest48(much delayed response ): I'm wondering if this is the same sort of failure path folks have seen with either device drivers not being loaded in time via a udev event to see your mounted ISO9660 config drive when cloud-init's ds-identify runs during systemd generator time frame. What you'd be able to check on your system is /run/cloud-init/ds-identify.log and it'll tell you while filesystems it sees during early boot.
[03:34] <blackboxsw> Guest48: I'm wondering if you are seeing the same symptoms as this bug https://bugs.launchpad.net/cloud-images/+bug/1940791/comments/8
[03:34] <ubottu> Launchpad bug 1940791 in cloud-init "sr0 not available at generator timeframe causes cloud-init.target not run" [Undecided, Triaged]
[03:37] <blackboxsw> In your case datasourceNone is still "viable" so cloud-init.target will still run, but I wonder about that race and NoCloud not being detected because of it
=== gschanuel2 is now known as gschanuel
=== EugenMayer9 is now known as EugenMayer
[16:04] <akutz> Howdy...hope everyone is well! Quick question, has there been any discussion of https://bugs.launchpad.net/cloud-init/+bug/1855945 since it was originally filed? I notice that @smoser is one of the authors of the RHEL distro, so maybe he can comment? Essentially we have discovered that Kubernetes node images built on top of RHEL 7 (I have not tested this with RHEL 8, so maybe it changed) do not work unless the "set-name" directive is used when
[16:04] <akutz>  configuring networking. Now, we all know CI introduced a few bugs around set-name recently, and while two are patched, there's reluctance to require its use. I'm just curious what people think about potentially building a patch so the sysconfig renderer can work without the use of set-name when the ethernets scalar does not match the device name.
[16:04] <ubottu> Launchpad bug 1855945 in cloud-init "Network Config Version 2 Device Configuration ID used as interface name when set-name is not specified" [Low, Triaged]
[16:11] <akutz> Or perhaps this *has* been patched post CI 19.4, the version of CI used by RHEL 7?
[16:13] <akutz> It does not seem to have been patched, but I think I can whip up a patch for it. I may give that a shot.
[16:20] <blackboxsw> akutz: I don't believe there as been followup on this topic, would have to dig into that a bit to get more context  on the impact of dropping set-name :/
[16:32] <akutz> I'm not suggesting we drop set-name 
[16:33] <akutz> Just that if set-name is not present, instead of defaulting to the scalar, use the device name from the dict returned by get_interfaces_by_mac by using the matched mac address.
[16:33] <akutz> (assuming that value is set of course)
[16:33] <blackboxsw> +1 akutz sorry, my response was short as we are mid SRU release validation for cloud-init at the moment. I *think* that element makes sense if absent.
[16:33] <akutz> I am fairly confident I can implement rather small patch in NetworkState.
[16:33] <akutz> No, your response was fine! I'm sure I did not explain things well, and you, like me, are willing to ask questions I'm sure others have. So it's good to get that out there.
[16:35] <blackboxsw> falcojr: holmanb per SRU validation I think related to whether or not to cherry-pick your single revert vs a new-upstream-snapshot I think we'd want to just cherry-pick the single commit for Oracle because there are risky comments like the introduction of NetworkManager renderer whose priority rendering ordering may cause us problems on some platforms and I'd like to iron that out before we try to SRU.
[16:41] <falcojr> blackboxsw: sounds good to me
[16:41] <blackboxsw> that commit plus the raise errors on EphemeralDCHP may need a bit more eyes/testing for failure modes
[16:44] <blackboxsw> though I think that ephemeralDHCP looks pretty well tied up given subclassing so maybe that's ok.
[16:46] <blackboxsw> in any event I'll get you the review now and try running the OCI test myself now too
[17:03] <blackboxsw> https://github.com/canonical/cloud-init/pull/1326 merged to backoff the Oracle config reordering. we can start on generating release branches starting with ubuntu/devel
[17:03] <ubottu> Pull 1326 in canonical/cloud-init "Revert 'Ensure system_cfg read before ds net config on Oracle (#1174)'" [Merged]
[18:58] <blackboxsw> falcojr: holmanb SRU uploads reverting  the Oracle config changeset uploaded, Bri-an mentioned he'd be able to review it
[18:58] <blackboxsw> thanks falcojr and holmanb 
[18:59] <blackboxsw> if it's approved as is, I'll also upload them to ppa:cloud-init-dev/proposed
[19:02] <akutz> I still need to add unit tests, but I submitted https://github.com/canonical/cloud-init/pull/1327 as patch for https://bugs.launchpad.net/cloud-init/+bug/1855945.
[19:02] <ubottu> Pull 1327 in canonical/cloud-init "Fix sysconfig render when set-name is missing" [Open]
[19:02] <ubottu> Launchpad bug 1855945 in cloud-init "Network Config Version 2 Device Configuration ID used as interface name when set-name is not specified" [Low, Triaged]
[19:23] <akutz> Is there a helper in CI for avoiding dumb errors like this? " AttributeError: 'str' object has no attribute 'case_fold'"
[19:26] <akutz> Nevermind, I'm an idiot :)
[19:32] <akutz> @falcojr, @blackboxsw -- is there anything I can do to help y'all during this release-prep window? 
[19:36] <falcojr> akutz: if there's any testing specific to your platform or use cases (though I know other VMWare testing has already been done) that you'd want to do from the Ubuntu proposed pockets, that'd probably be the most helpful
[19:36] <falcojr> work happening today is just doing some re-uploads because a bug was found during testing
[19:37] <akutz> @falcojr: I actually already did one thing on that end beyond the baseline testing :) https://github.com/kubernetes-sigs/image-builder/pull/824 -- turns out deepmerge (which was used in an older version of the old, external DS) versioned itself on PyPi to no longer support Python2 (RHEL 7), and so we couldn't build new images due to the CI DS dep :(
[19:38] <akutz> Aside from that, I saw the e-mail from Canonical and validated everything else on Ubuntu -- looked good from my end :)
[19:39] <falcojr> my condolences that you're still dealing with python 2 
[19:39] <falcojr> and thanks for that testing, it helps build confidence that we're not breaking anything
[21:34] <Guest7> hi. why my network configure didn't work? Have I done something wrong? (https://gist.github.com/RaminNietzsche/2ad55648b98bc713ef900f85cd384c69)
[21:51] <akutz> This has to be one of the more passive aggressive test errors ever :) "AssertionError: False is not true"
=== janitha9 is now known as janitha