Support type 'list' for output_wrapper_field_path

[brycahta]

Is your feature request related to a problem?
I am unable to generate Instance CRD for ec2-controller because code-generator cannot unwrap the list responses from RunInstances and DescribeInstances, the Create and List operations, respectively.

RunInstances is a "create many" call in that a single request can create multiple instances. As a result, the output shape returns a list of Instances (within a Reservation struct). Similarly, DescribeInstances returns a list of Reservations each containing a list of Instances.

The Instance CRD implementation will only allow requesting/creating a single instance at a time; therefore, we only want the first instance in the RunInstances output shape, Reservation.Instances[0], and the first instance of the first reservation in the DescribeInstances output shape, Reservations[0].Instances[0].

Describe the solution you'd like
Extend the functionality of output_wrapper_field_path config to support type "list" (only supports struct today). Unwrapping a list element will always take the first element.

Desired generator.yaml for Instance:

  RunInstances:
    output_wrapper_field_path: Reservation.Instances
    operation_type:
      - Create
    resource_name: Instance
  DescribeInstances:
    output_wrapper_field_path: Reservations.Instances
    operation_type:
      - List
    resource_name: Instance

• refactor setResourceReadMany to setListResource (or something similar) and use this function for ReadMany and unwrapping list elements.

Describe alternatives you've considered

• map RunInstances to CreateBatch operation and create a setResourceCreateMany()

[jaypipes]

@brycahta for the List operation, we have a ListOperationConfig.MatchNames thing that is supposed to handle this kind of problem for scenarios where the list operation returns a list of structs. I agree with you that we have no facility to handle scenarios where the list operation returns a list of structs of lists of structs :)

I think your proposal here is a good one.

[jaypipes]

Basically, we want to make this piece of code configurable...

[eks-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/aws-controllers-k8s/community.
/lifecycle stale

[a-hilaly]

/lifecycle frozen