Fix lo being used for DHCP, try next on cmd fail

[eb3095]

Proposed Commit Message

Fix lo being used for DHCP, try next on cmd fail

Arch didn't like the last fix and lo found its way into this list. Checking for this and skipping interfaces that generate subp failures.

Test Steps

Deployed Arch on Vultr

Checklist:

• [ X ] My code follows the process laid out in the documentation
• [ X ] I have updated or added any unit tests accordingly
• [ X ] I have updated or added any documentation accordingly

[cjp256]

This check would now fail to filter out numbered dummy interfaces, e.g. "dummy0".

FWIW I've been considering taking the filtering done for net.find_fallback_nic() and providing a method so we can query the set of viable interfaces without the data sources having to add similar filtering logic for themselves if fallback_interface is not sufficient.

[cjp256]

FYI: something like this https://github.com/canonical/cloud-init/pull/1209/files

[eb3095]

Ah indeed it would. Not sure why I didn't see that... Anyways its fixed, and it looks like find_candidate_nics is exactly what I need. Once that's merged in I will immediately refactor this to use that instead. Probably when I go through and simplify the generation of our metadata. I am looking at making a new endpoint on our end that feeds cloud-init format configs directly instead of doing what we are doing here to eliminate some of these inconsistencies we are seeing due to our metadata bumping heads with the cloud-init format here and there.

[eb3095]

Seems like travis is stuck here? Am I able to kick that from my end to get it going? I dont see an option.

[TheRealFalcon]

Hey @eb3095 , it should work now if you push anything to the branch. If there's nothing new, you can force push a trivial change (i.e., an extra space) in the commit message.

[TheRealFalcon]

Thanks!