Adding An AWS Service

New AWS service

Adding a new AWS API service to awless is an important process that needs to be crafted patiently.

This process is basicallyreviewing the cumbersome/exhaustive params/attributes for a given AWS service and adapting them intelligently to awless commands/models.

It means that the awless CLI will be augmented. For instance adding ELB Classic Load Balancer, the following CLI commands/models would come to life:

1. Listing your new entity with relevant and enrich properties: awless list classicloadbalancer ...
2. CRUD on your new entity: awless create classicloadbalancer name=... vpc=... (also awless delete/attach/detach/update classicloadbalancer)
3. Show more properties for your new entity: awless show my-classic-loadb
4. Your new entity is transparently synced and now part of the local graph model. Relations from your new entity to already existing entity in the model have been built as well.

What kind of AWS service add value to ? Usually, infrastructure centric AWS API (EC2, ELB, S3, IAM, etc.) add the most value to awless since they complement and enrich the existing awless model of your infrastructure. AWS service that stands more on their own and do not enrich the infrastructure local graph can be added, but they have less relations with existing entities. Do not forget that each AWS service added to awless add more data to sync and grow the model.

Now this commit that added the support of Classic ELB is a very good real life example and a full reference to understand on how to integrate a new service.

Note that files in this commit starting by gen_ are generated (since the documentation on code generation in awless) ()

• acceptance/aws/gen_factory.go
• acceptance/aws/gen_mocks.go
• aws/doc/gen_paramsdoc.go
• aws/fetch/gen_fetchers.go
• aws/services/gen_mocks_test.go
• aws/services/gen_services.go
• aws/spec/gen_cmds_defs.go
• aws/spec/gen_inits.go
• aws/spec/gen_runs.go
• cloud/rdf/gen_rdf.go
• cloud/properties/gen_properties.go

This commit is self documenting on the process but it can be a bit hard to see whats is going on, so let us point to some important files from this commit :

• acceptance/aws/classicloadbalancer_test.go: main Test Driven file that you start from when you design a new service. That is where you can start thinking of how the commands will behave and look like. This is behaviour driven development.
• aws/conv/convert.go (and aws/conv/convert_test.go):
• aws/conv/model.go:
• aws/doc/clidoc.go:
• aws/doc/paramsdoc.go:
• aws/fetch/config.go:
• aws/services/relations.go:
• aws/services/services_test.go:
• aws/spec/classicloadbalancer.go:
• aws/spec/setters.go:
• aws/spec/setters_test.go:
• cloud/cloud.go:
• console/defaults.go:
• gen/aws/fetchers_definitions.go:
• gen/aws/generators/paramsdoc.go:
• gen/aws/mock_definitions.go:
• gen/aws/properties_definitions.go:
• graph/resourcetest/resourcetest.go:
• template/internal/ast/entities.go:
• template/revert.go (and template/revert_test.go):