Verify and fully implement ec2_instance network option logic

[Helen Bailey]

Summary

While reviewing this bugfix PR, it seems like the build_network_spec function still needs more work to fully implement the logic in the API's network interface specification (as evidenced by the function's TODO: more special snowflake network things comment). For example, many of the suboptions have limitations on the AWS side such as "You cannot specify this option if you're launching more than one instance in a RunInstances request" and "Applies only if creating a network interface when launching an instance". We should verify which limitations apply, ensure they are enforced in our code, and where possible add tests for this.

In addition, I find the entire network option for this module to be a bit confusing as it requires either "a dictionary containing the key C(interfaces) corresponding to a list of network interface IDs or containing specifications for a single network interface." While this would potentially result in breaking changes to the module, I think it's worth considering whether there are approaches that would be more clear for both the end user and the internal logic. For example we could update the current network option to just take a list of interfaces (with the ENI ID as one possible suboption for each list element), and/or we could add a new option to allow providing a list of ENI IDs separate from the option for a single network interface's specifications. Other ideas welcome, these are just my initial thoughts.

Issue Type

Feature Idea

Component Name

ec2_instance

Additional Information

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[C C Magnus Gustavsson]

Fully agree on the network option being unnecessarily confusing (and just taking a list of interfaces sounds reasonable to me).