awslabs / aws-shell

An integrated shell for working with the AWS CLI.
Apache License 2.0
7.15k stars 770 forks source link

Reference other services' resources from server side completions #80

Open quiver opened 8 years ago

quiver commented 8 years ago

This is a feature request.

Usecase

elb attach-load-balancer-to-subnets API accepts

and you want to autocomplete both parameters.

Problem

At completions-1.json, operation assumes you call API of the same service, and subnet retrieval API belongs to a different service(ec2), you cannot define subnet resource outside of ec2.

  "resources": {
    "Subnet": {
      "operation": "EC2:DescribeSubnets", <-- DOES NOT WORK 
      "resourceIdentifier": {
        "Id": "Subnets[].SubnetId"
      }
    }
jamesls commented 8 years ago

The resource models the AWS SDKs use right now don't support this yet which is why it isn't in the aws-shell, but I'd like to add this.

The two options I see are:

1) Denormalize the resources as you've done here. This means that within the elb completions, you'd redefine the same subnet in the EC2 completions. This makes the implementation simple because we know as soon as you type elb all the completions we need will come from a single file. Also makes it easier to read these completions because you don't have to jump around multiple files.

2) Allow some way to reference resources defined in other files. Something like:

in elb/<api>/completions-1.json:

"AttachLoadBalancerToSubnets": {
  "Subnets": {
    "resourceName": "ec2.Subnet",
    "resourceIdentifier": "Id"
  }
}

In this case, the completer would see "ec2.Subnet", load the completions for ec2, and then use the Subnet in resources. Given that these files aren't going to be 100% auto generated from resource models, I'm slightly inclined for option 2 because it seems easier to manage by hand, e.g if there's a bug in the JMESPath expression for getting subnet IDs, we'd just have to fix it in one place.

Thoughts?

quiver commented 8 years ago

If we choose the option 1, we have to copy-and-paste common resources everywhere, and I don't think we can maintain them in the long run. In that sense, I'd go for the option 2.