Confusing pluralization of some EC2 objects that are inconsistent with AWS names

[pdpol]

Discovered this on 4.3.2, but it looks like this is true of the currenbt state of main as well.

When working with launch templates, several of the properties of LaunchTemplateData are lists of other objects, for example NetworkInterfaces. In troposphere the singular objects that make up the elements of these lists have plural names such as NetworkInterfaces, or TagSpecifications. There are links in the definitions of these objects to the corresponding AWS Cloudformation objects, named NetworkInterface and TagSpecification respecively.

I think it's probably not intended to be this way and is confusing to figure out that I need to pass a list of NetworkInterfaces to a list property called NetworkInterfaces, rather than a list of NetworkInterface objects.

One exception to this issue is the BlockDeviceMappings property, which takes a list of an object called LaunchTemplateBlockDeviceMapping. This also does a nice job of disambiguating with the BlockDeviceMapping used by the ec2 Instance object. Maybe something similar would work for NetworkInterfaces, TagSpecifications, and the other list properties of LaunchTemplateData?

[markpeek]

Yes, you are correct about some of the naming of the objects. The short answer is "historical" and "backward compatibility".

The longer answer is more convoluted. This project started in 2012 by hand-writing the code from the CloudFormation (CF) docs. This took time to figure out the new objects and track changes to the existing items. And as new things were added by to CF, there were objects (with different attributes) with the same name being used. This caused us to then use our historical naming even if it wasn't as clear and use different names for the new objects.

Over time AWS refined their docs and created a resource specification to more accurately specify the object names and types. But it wasn't until troposphere 4.0.0 in early 2022 that the main troposphere code was auto-generated from the specification. One of the goals for 4.0.0 was to make as few breaking changes as possible to be able to validate the new auto-generated code and allow for easier transition for existing scripts. There are a large number of backward compatibility patches such as the NetworkInterfaces one you mentioned and a lot of these changes are to the early CF resources such as EC2.

At some point it might make sense to remove as many of the backward compatible changes in a new major revision but I would want to hear from the community before proceeding on that endeavor. It would likely break all existing scripts and that could cause adoption issues for the new version. I'm just not sure whether the community would think this is worth the significant renaming involved. I hope this helped explain the issue you raised.

[pdpol]

Thanks @markpeek that all makes sense. I appreciate hearing the backstory!