README: Note that primary ENI isn't always eth0

[ewbankkit]

We should update the README to note that the primary ENI isn't always eth0 (e.g. for instances with enhanced networking or running newer CentOS/RHEL, see discussion: aws/amazon-vpc-cni-k8s#171, aws/amazon-vpc-cni-k8s#190, aws/amazon-vpc-cni-k8s#193), calling out the case of negative prefixes introduced in #54,
Also, given that the primary ENI is kind of non-deterministic, maybe we could have a logical host-interface value like not-the-primary-eni (just a strawman 😄) that could be converted to the correct IPTables expression at runtime?

[pingles]

Interesting. Could you add a few more examples of what the flags would look like?

I quite like the idea of something that could specify --cni=calico etc. that'd take away some of the pain, or try and autodetect it from the metadata, but I feel like that should probably be in addition to allowing operators to specify the expression.

There's definitely been more than a few issues created where people hadn't expected to need to configure it so having something to reduce the surprise would be good.

[ewbankkit]

Yes, a --cni flag with values such as awsvpc, calico, weave etc. could be added.
The --host-interface flag would of course still be supported for those cases where there was no corresponding cni value.

[pingles]

Cool- I guess it’d be useful to know whether the expressions are always known for each CNI but I guess we could just list the expected ones. It'd definitely make it easier for folks!

…

On Thu, 1 Nov 2018 at 11:59, Kit Ewbank ***@***.***> wrote: Yes, a --cni flag with values such as awsvpc, calico, weave etc. could be added. The --host-interface flag would of course still be supported for those cases where there was no corresponding cni value. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAEfiD-mO2Jju7GzTWpXe33XOSvuplWks5uquI5gaJpZM4X8IAE> .