Add possibility to limit the list of examined network interfaces during fact gathering

[MerlinDMC]

We run Ansible against hosts that have more than 100 network interfaces configured. The setup task does take multiple minutes to complete which results in problems in our day to day operations.

We know exactly that we're only interested in a limited subset of interfaces facts so we need to limit the examined data.

This patch allows us to limit the fact gathering via a configuration entry like:

gather_network_interfaces = lo*,eth0,eth1

The overall gain here is the runtime for each setup task which drops from multiple minutes (2 - 10 minutes depending on the instance) to about 5 seconds.

This PR needs the additional change in ansible/ansible-modules-core#4865

[alikins]

Looking at this for 2.3.

Looking deeper at the network interface info collection code, I think there are some easy optimizations to be had there I'd like to address for 2.3, so that could help as well.

More generally, if the faces code were to try to attempt to detect the 'useful' network interfaces and potentially only collect those by default, is there any selection heuristic that would be useful?

[MerlinDMC]

@alikins sorry it took a while until I could start answering.

About the selection heuristic: I think that is pretty impossible to predict since every operator can easily rename interfaces the name can't be used as the source of validity. In order to look deeper at the interface and do selections on other facts you already have to invest the time and gather all the information in order to select what to throw away - which also just feels wrong.

Imho the only viable option is to let the person running the tasks decide what is important for their actual situation.

In addition to that my code here also fetches the device for the default route and includes the interface that one is bound to so that (I hope) all the other standard module get enough information to operate without errors.

It might be useful to have include and exclude lists ... but I'm not sure if I would come into a situation where a include list with placeholders is not enough.

To give an overview of what our current situation looks like:
We have services deployed via a normal bridged network using docker on multiple host servers. Each of those servers will run > 100 of those and each container by default will generate a generic named interface attached to the bridge.

lo
eth0
docker0
vethc14cb32
veth76e6b45
...a lot more...
vethffacc63
vethf898333

And yes in this example it's obvious: remove all /^veth/ and the rest is pretty sensible.
But this naming will be different in future iterations of the platform so it will push us into the same issue again unless we can explicitly specify what at that point in time is important to gather.

[ansibot]

@MerlinDMC Greetings! Thanks for taking the time to open this pullrequest. In order for the community to handle your pullrequest effectively, we need a bit more information.

Here are the items we could not find in your description:

• issue type

Please set the description of this pullrequest with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/PULL_REQUEST_TEMPLATE.md

click here for bot help

[sivel]

Thank you very much for your submission. We have discussed this and decided against accepting this feature at this time.

Feel free to stop by the #ansible-devel channel, or during a core IRC meeting to discuss this issue and come the a consensus on an alternate approach.

If you have further questions please stop by IRC or the mailing list:

• IRC: #ansible on irc.freenode.net
• mailing list: https://groups.google.com/forum/#!forum/ansible-project