grains/core: ignore HOST_NOT_FOUND errno in fqdns()

[aplanas]

What does this PR do?

We ignore also HOST_NOT_FOUND errno (actually h_errno) when trying to recover the fqdn.

Fixes #52788

[aplanas]

Is ready for review. @isbm what do you think?

[brejoc]

lgtm

[waynew]

@aplanas would it be reasonable to use the "warn once" method that we have elsewhere in the code, or does it make more sense to always ignore it?

[aplanas]

Oh I like the idea. Makes sense for me. I will check how this was done before.

[aplanas]

@waynew maybe I will need a bit of help here. The only place that I found where there is some kind of repetition filter for warnings is in __init__.py, but this is related with exceptions, and not with logs.

[aplanas]

this is potentially a bug, can we tag it for Neon?

[waynew]

@aplanas I'll bring it up with @saltstack/team-core, but my feelings are that it should get in with the Neon release.

[aplanas]

The clint complain is about this:

salt/grains/core.py:51: [W1505(deprecated-method), linux_distribution] Using deprecated method _deprecated_linux_distribution()

As I do not touch this piece of code at all, can we review the patch? This is taking too long IMHO.

[waynew]

Hey @aplanas sorry for the delay. https://github.com/saltstack/salt/blob/216e3a7f9991ad3f1650841a744e7eb2c60a8a1f/salt/grains/core.py#L44 Looks like we should just tell lint to ignore that line, apparently we're already aware of it - especially if we want to put this change into neon as well. If we're just going into the Sodium release we should be able to just remove the entire other block of code.

Hm. Actually now that I look closer - maybe we should just rely on distro in general 🤔 Though I'm not actually seeing it in requirements anywhere 😕

[aplanas]

Looks like we should just tell lint to ignore that line, apparently we're already aware of it - especially if we want to put this change into neon as well. If we're just going into the Sodium release we should be able to just remove the entire other block of code.

I like your idea. If Sodium is Python3 there is no reason to maintain the old code that makes it compatible with Python2. Let me add an extra patch for this.

Edit: I just saw a disable=W1505 in the new master, I will rebase then! But I still like the idea.

[aplanas]

Rebased into the new master (from develop), any chance now?

[waynew]

Hey @aplanas this is looking great (and, apologies for the lengthy process on this one 😞 )

Would you be able to write a test for this? I'm hoping that it shouldn't be too much effort and we have something already testing around this area...

[aplanas]

@waynew I added a test. Can you re-review?

[waynew]

🚀 Sweet action!

I know we currently have some issues around our Mac testing infrastructure that we're working on, but otherwise this should be ready to go. I did notice some Centos failures that I need to check out before we merge this.

[waynew]

Ah. It was a test from an unrelated thing (we do still need to fix that, so we'll probably need to do one more rebase 🤞 after we fix the mac/other issue elsewhere)

[aplanas]

I am loosing hope that this, or any of my others PR will be merged ever: there is no way to have a green CI result after almost one year of rebasing (or moving the code between branches) (Edit: sorry, I was a bit frustrated)

We have 49(!) checks in place, but they are still randomly failing, making very hard to differentiate between an useful failing report, from noise.

Can we have a more strict policy in place, where we trade off a super big number of checks with reliable ones? For example, if ci/py2/macosxmojave is broken, lets disable it with urgency before re-adding it once that is fixed.

[aplanas]

ci/py3/debian10 fail seems unrelated:

11:51:30         ======================================================================
11:51:30         FAIL [29.945s]: test_pkg_latest_version (integration.modules.test_pkg.PkgModuleTest)
11:51:30         ----------------------------------------------------------------------
11:51:30         Traceback (most recent call last):
11:51:30           File "/tmp/kitchen/testing/tests/support/helpers.py", line 121, in wrap
11:51:30             return caller(cls)
11:51:30           File "/tmp/kitchen/testing/tests/support/helpers.py", line 1154, in wrapper
11:51:30             return caller(cls)
11:51:30           File "/tmp/kitchen/testing/tests/support/helpers.py", line 1077, in decorator
11:51:30             return func(*args, **kwargs)
11:51:30           File "/tmp/kitchen/testing/tests/integration/modules/test_pkg.py", line 362, in test_pkg_latest_version
11:51:30             self.assertIn(pkg_latest, cmd_pkg)
11:51:30         AssertionError: "ERROR: E: Repository 'https://repo.saltstack.com/apt/debian/9/amd64/latest stretch InRelease' changed its 'Suite' value from 'stable' to 'oldstable'" not found in '\nWARNING: apt does not have a stable CLI interface. Use with caution in scripts.\n\nListing...\nfiglet/stable,now 2.2.5-3 amd64 [residual-config]'

[aplanas]

This is as green as I can get. The current fails, IIUC, are timeouts. I am not able to diagnose the reason of the VM timeout, tho.