Add parameter named grains_blacklist

[rongzeng54]

What does this PR do?

Add parameter named grains_blacklist to block the specific grains.

What issues does this PR fix or reference?

No

Previous Behavior

The default grains list, seems getting longer and uncontrolled by the user.

New Behavior

The user finally has a chance to say no.
Of course, only for advanced users because of the dependencies of module.

Tests written?

No

Commits signed with GPG?

No

[cachedout]

Overall, I like the idea of this feature but I'm not certain about this implementation.

Would it not be more efficient to just filter at the point that the grains themselves are generated versus doing this on the instantiation of the LazyLoader? I wonder if we should move this logic to the grains() function in the loader. Let me know what you think, @rongzeng54

[rongzeng54]

@cachedout
Thank you for your reminder. Please check the new commit.

[cachedout]

This is much better. I like this a lot.

[cachedout]

@terminalmage You feel good about this?

[terminalmage]

This needs to have documentation added in doc/ref/configuration/minion.rst.

In addition, all other whitelists/blacklists that we support in salt use salt.utils.stringutils.expr_match() to support exact matches, fnmatch.fnmatch() matches, and regex matches. We should be using it here as well for consistency.

Lastly, rather than doing type checking, we should be setting a default value for this in DEFAULT_MINION_OPTS in salt/config/__init__.py. For example:

'grains_blacklist': [],

There should also be an entry for this option in VALID_OPTS as well, with the valid type being list.

[rongzeng54]

Hi @terminalmage
Thanks for your reminder. Already fixed.

[rongzeng54]

Hi @terminalmage
Please check again.

[isbm]

Why this is even needed at all? If there is something in the default list, then it needs to be there anyway. If you want only specific keys, then you can already get them. But once you need something that you normally do not need and this "muter" exist, then you have a trouble.

I find this useless, sorry.

[rongzeng54]

@isbm
Useless data wastes server-side storage space, bandwidth caused by data synchronization, even speed.
As described, It is not for everyone.

[isbm]

@isbm
Useless data wastes server-side storage space, bandwidth caused by data synchronization, even speed.
As described, It is not for everyone.

Then simply don't ask for all data. Ask only for what you need. But once you do need it but at the same time cannot get it, then I find this a very bad idea.

[rongzeng54]

@isbm
Useless data wastes server-side storage space, bandwidth caused by data synchronization, even speed.
As described, It is not for everyone.

Then simply don't ask for all data. Ask only for what you need. But once you do need it but at the same time cannot get it, then I find this a very bad idea.

The following is the configuration of our production environment, we believe that we cannot need them, but we also believe that others may need.

grains_blacklist:
  - 'lsb_distrib_codename'
  - 'lsb_distrib_id'
  - 'lsb_distrib_release'
  - 'cpu_flags'
  - 'fqdn_ip4'
  - 'fqdn_ip6'
  - 'num_gpus'
  - 'gpus'
  - 'locale_info'
  - 'machine_id'
  - 'pythonpath'
  - 'saltversioninfo'
  - 'pythonversion'
  - 'server_id'
  - 'saltpath'
  - 'domain'
  - 'localhost'
  - 'ip4_interfaces'
  - 'ip6_interfaces'
  - 'zmqversion'
  - 'SSDs'
  - 'disks'
  - 'mdadm'
  - 'username'
  - 'groupname'
  - 'uid'
  - 'gid'
  - 'systemd'

[rongzeng54]

Hi @terminalmage
It seems that all the problems have been solved.

[rallytime]

Can you write some tests for this new functionality? We wouldn't want this to regress in the future. :)

[rongzeng54]

Can you write some tests for this new functionality? We wouldn't want this to regress in the future. :)

Hi @rallytime . It is done.

[rallytime]

Thanks @rongzeng54!

[max-arnold]

This option seems to partially duplicate the existing disable_grains parameter (briefly mentioned in #42567).

IMO, having two different ways to do this is confusing.