[04:28] <ani> s there somewhere that talks about how to install all the necessary import modules? Like a pip requirements ?
[04:29] <ani> I am getting this error
[04:29] <ani> E   ModuleNotFoundError: No module named 'configobj'
[04:29] <ani> ERROR: InvocationError for command /home/cavery/build/cloud-init-centos/ani-cloud-init/cloud-init/.tox/py3/bin/python -m pytest -vvvv --showlocals --durations 10 -m 'not hypothesis_slow' --cov=cloudinit --cov-branch tests/unittests (exited with code 4)
[04:49] <ani> i see https://github.com/canonical/cloud-init/blob/main/test-requirements.txt and https://github.com/canonical/cloud-init/blob/main/requirements.txt
[04:59] <holmanb> Hi ani o/
[05:01] <holmanb> ani: tox should automatically handle that
[05:03] <holmanb> But yes, the files you mentioned should provide the required dependencies for unit tests
[05:05] <holmanb> i don't know that we document it explicitly for users - test deps should be handled by tox automatically and packaging should already work, so i don't think there's really an expectation for users to need to know which external module dependencies to provide
[05:17] <holmanb> Also I just tested with tox from epel on centos 9 stream, looks like tox installed deps correctly with `tox -e py3`
[05:19] <holmanb> Although two tests just failed... 
[05:20] <holmanb> Heh, okay tar is a unit test dependency I guess
[05:45] <ani> OK
[16:56] <holmanb_> weeeeeee
[16:56] <holmanb_> all the bsd PRs
[16:56] <holmanb_> meena: when you get a chance could you peak at this one: https://github.com/canonical/cloud-init/pull/4683
[16:56] -ubottu:#cloud-init- Pull 4683 in canonical/cloud-init "fix: IscDhclient discover DHCP leases on FreeBSD" [Open]
[16:56] <holmanb_> oh hi ubottu, ears burning?
[16:58] <holmanb_> meena: it's pretty short: +7/-1 for LOC changes, plus tests
[17:22] <meena> holmanb: looking
[17:24] <meena> holmanb: what does "This change adds allows discovering such lease files." this mean?
[17:25] <holmanb> "such" could be substituted with "those" in that sentance
[17:26] <holmanb> It's referring to the leases at that path
[17:29] <meena> "adds" vs "allows" feels like an either/or thing
[18:59] <Code_Bleu> meena: holmanb: I thought I tested this on OpenBSD before and it worked, but now I'm not sure.  Now when I run 'cloud-init analyze show' I get this - https://sprunge.us/begTkI
[19:00] <meena> Code_Bleu: did you delete the appropriate .pyc files before applying the patch?
[19:02] <Code_Bleu> meena: pretty sure before I created this image I'm working with I manually cleared out everything and even ran pip uninstall cloud-init , rm -rf /run, cloud-init clean --logs...etc
[19:06] <meena> Code_Bleu: so you're testing this patch, or what exactly are you testing right now?
[19:07] <Code_Bleu> meena: I'm not really testing anything.  I'm on an instance of OpenBSD that I created  several days ago ...right have my PR was merged.  I just so happened to connect to it and run the 'cloud-init analyze show' and got that error
[19:07] <meena> aaaah
[19:07] <meena> okay, so we need to fix that then.
[19:08] <meena> that works somewhat betterer on FreeBSD, so we want at least that level of support in allBSD
[19:08] <Code_Bleu> are you able to confirm on your end that it is an issue and it's just not me 😉 
[19:08] <meena> Code_Bleu: can you open a bug for that?
[19:09] <meena> need to put kiddo to bed now, so I'll take care of it after
[19:09] <Code_Bleu> 👍 
[19:15] <Code_Bleu> meena: disregard.  I'm an ID10T.  My stupid logs were 0 bytes in size, so I must have cleared it or something.  So, obviously the analyze wont work without data to analyze :facepalm:
[19:22] <meena> why not tho?
[19:25] <meena> I would expect more sensible error message than a cryptic exception 
[19:31] <holmanb_> thanks for reviewing that meena
[19:32] <holmanb_> we've talked about making that function distro-specific before, I think (in a review of some different code, iirc)
[19:32] <holmanb_> or maybe that was with minimal?
[19:33] <holmanb_> while back, can't remember
[19:33] <meena> the getter functions at least
[19:33] <holmanb_> yeah exactly
[19:34] <holmanb_> the filename check I don't care about so much, that's just checking string values in memory
[19:35] <Code_Bleu> meena: good point.  have it check if logs are not 0 bytes for starters 😄 
[19:35] <holmanb_> wait
[19:35] <holmanb_> oh nvm
[19:36] <holmanb_> Code_Bleu: agreed, if we can report better errors, we should
[19:36] <holmanb_> meena: and moreso to make it easier to refactor in the future into methods in distro/
[19:42] <Code_Bleu> https://github.com/canonical/cloud-init/issues/4686
[19:42] -ubottu:#cloud-init- Issue 4686 in canonical/cloud-init "cloud-init analyze on OpenBSD needs better error handling" [Open]
[19:43] <Code_Bleu> meena: holmanb_ ^
[20:02] <holmanb_> Code_Bleu: appreciated
[20:19] <meena> Code_Bleu: i would venture a guess that this particular behaviour won't be restricted to OpenBSD 
[20:25] <Code_Bleu> meena: I was thinking the same thing, but thought I'd be specific and not assume it did work on other OS or other BSD.  If ya'll think it makes sense, I can remove 'OpenBSD' from the bug.
[20:26] <Code_Bleu> I'll leave the Env details of the OS I ran it on OpenBSD, but I'll update the description to just be generic.
[20:27] <Code_Bleu> meena: updated
[20:50] <meena> Code_Bleu: thanks.
[20:55] <Code_Bleu> meena: well 💩  We prob should have updated the 'build-on-openbsd' to remove the dmidecode with your #4654 PR ?
[20:57] <Code_Bleu> https://github.com/canonical/cloud-init/blob/4006c23cba5a5e65f0dba4db97491a09cd9a851e/tools/build-on-openbsd#L15
[21:47] <holmanb> Ah well, we can do that in a followup Code_Bleu 
[21:49] <holmanb> Code_Bleu: have you tried running unittests on OpenBSD? 
[21:49] <holmanb> Curious if they pass
[21:52] <meena> holmanb: my guess is that more tests fail than on FreeBSD… and on FreeBSD currently only 2 tests fail with python netlink patches
[21:52] <meena> OpenBSD has no netlink, so those will fail for sure, and should be excluded from running / expected to fail on not (Linux / FreeBSD)
[21:53] <meena> I still haven't figured how to fix those damn ls output tests
[21:53] <meena> Code_Bleu: tox -e py3 # should do everything needed, but you'll need tox and bash as a start
[21:59] <meena> Code_Bleu: the next iteration should be to make dmidecode the fallback on OpenBSD
[22:14] <meena> holmanb: need to fix this one https://gist.github.com/igalic/d7770b21294d95bfdbae505e122d0a68
[22:15] <holmanb> tar is also required if it's not already installed 
[22:18] <meena> holmanb: tar is in the base system on BSDs
[22:18] <meena> on OpenBSD, perl is still in base@
[22:26] <Code_Bleu> holmanb: meena: I have ran tox -e py3 before, but not sure how that relates to not removing the dmidecode from the 'build-on-openbsd'.  Or maybe you were asking for other reasons?
[22:27] <meena> Code_Bleu: how badly does tox -e py3 fail on OpenBSD?
[22:28] <Code_Bleu> I had tested using meena's fix before it got merged and had dmidecode removed from my test system and it all worked.  I just didn't remove it from my PR since meena's PR hadn't been merged yet and forgot to mention to have that just removed from the build-on-openbsd as a package requirement.
[22:29] <meena> Code_Bleu: to be fully functional, it's still a dependency, but now it's very optional
[22:29] <meena> given that we kinda cover  75% of all requests that our sources ask of dmidecode
[22:29] <Code_Bleu> meena: correction.  I ran the tox -e py3 on the repo that was on my local Gentoo box.  I never ran it on OpenBSD itself.  I just ran it for purposes of getting tired of pushing commits up and the CI fail :P 
[22:31] <Code_Bleu> meena: so we just plan on keeping dmidecode as a package that the build-on-openbsd is going to install?
[22:31] <meena> Code_Bleu: i'm torn, but my instinct is to rip it out
[22:36] <meena> holmanb: those ls tests already have @pytest.mark.parametrize, i wonder if i can use that to say, this is what it says on busybox / BSD
[22:46] <meena> minimal: how come we have no cloudinit.util.is_Alpine() ?
[23:07] <meena> I have committed a crime: https://gist.github.com/igalic/b4ff1fefad329331f43d1f74bfdc44c9
[23:07] <minimal> holmanb: which function were you referring to?
[23:12] <minimal> meena: isn't that covered by is_Linux() ?
[23:12] <meena> minimal: no, busybox ls and gnu ls work differently
[23:13] <minimal> ok, but that has nothing to do with Linux / not Linux
[23:13] <meena> busybox and BSD agree on the output, but disagree on the return code 
[23:14] <minimal> so where are you expecting that any is_Alpine() function may be needed?
[23:14] <meena> really, so far, just for this stupid test
[23:14] <minimal> which test?
[23:14] <meena> maybe i should rewrite it to something more sensible
[23:14] <meena> see this patch, https://gist.github.com/igalic/b4ff1fefad329331f43d1f74bfdc44c9
[23:17] <minimal> Alpine can have either Busybox tar or "fall fat" tar installed, do determining if code is running on Alpine does not indicate which version of tar is installed...
[23:17] <minimal> the only way to know is do so "tar --version" or equivalent