Krikri::PluginHelpers::Ec2Info
Read-only lookup logic for the amazon.aws EC2 Describe* info modules (ec2_vpc_subnet_info, ec2_vpc_net_info, ec2_ami_info) through the shared PluginHelpers::Ec2Api signed-request helper - see that helper's comment for the credential/region resolution contract (AWS_* env vars, region param fallback). No state/idempotency: each run is one Describe call (plus, for VPCs and AMIs, the same per-result attribute calls real Ansible makes) with the result list shaped the way the real modules shape it.
Result shaping parity: the real modules pass the whole boto3 item
through camel_dict_to_snake_dict (so every CamelCase response key
becomes snake_case, nested sets included), add an id key for
backwards compatibility (subnets/VPCs), and overwrite tags with
a tag-key -> tag-value dict. The generic XML converter here
reproduces exactly that from the EC2 XML wire format: element
names are camel_to_snake'd, <item>-repeated sets become lists,
and tagSet becomes the tags dict.
Class methods
ansible's camel_dict_to_snake_dict, applied to XML element names. Handles the acronym runs boto responses contain (DnsSupport, Ipv6CidrBlock, EnaSupport) the same way Ansible's regexes do.
One EC2 XML response element -> the JSON::Any boto3 would have
returned and camel_dict_to_snake_dict would have shaped: leaf
elements become strings, <item>-repeated sets become arrays,
tagSet becomes the tags dict, everything else becomes an object
with camel_to_snake'd keys.
The filters param arrives as a JSON dict string of AWS filter name -> value or list of values (the same string-hash the plugin binary receives), e.g. {"tag:Name": "web"} or {"vpc-id": ["vpc-1", "vpc-2"]}.