dikhan / terraform-provider-openapi

OpenAPI Terraform Provider that configures itself at runtime with the resources exposed by the service provider (defined in a swagger file)
Apache License 2.0
274 stars 48 forks source link

Support for non-hierarchical sub-resource/data source names #327

Open arjunrajinstaclustr opened 2 years ago

arjunrajinstaclustr commented 2 years ago

Is your feature request related to a problem?

The auto-generated resources and schemas seem to enforce a hierarchy in its naming.

The following is a example of a GET list request:

paths:
    '/api/v2/things/v1/{thingId}/subs/v1':
        get:
            tags:
                - Subs
            responses:
                '200':
                    description: Gets the subs
                    schema:
                        type: array
                        items:
                            $ref: '#/definitions/SubsV1'
            description: Gets the subs
        parameters:
            -
                name: thingId
                in: path
                required: true
                type: string
        x-terraform-resource-name: subs_v1
definitions:
    SubsV1:
        title: Root Type for SubsV1
        description: ''
        type: object
        properties:
            id:
                type: string
            status:
                description: ''
                type: string
        example:
            id: myId

The above gets converted into a data source named - myprovider_v1_subs_v1, which is because of my pathing convention where I place versions after the resource nouns.

Additionally, the path parameter thingId gets converted into a required argument named v1_id.

Describe the solution you'd like

Probably by using a new meta-attribute, I would like a way to fully customise the name for my sub-resource or sub-data source and not rely on any smarts from the plugin. Desired outcome - myprovider_subs_v1

I would also like to have a way to customise path parameter IDs. Desired outcome - thing_id. I see this as directly related to the above issue but let me know if I should open up a separate issue for the path parameter naming problem.

Acceptance criteria

Meta attributes are available to -

  1. Fully customise the name of sub-resources and sub-data sources such that the parent resource names are not added to the resource/data-source names.
  2. x-terraform-field-name is applicable to path parameters as input arguments.

Describe alternatives you've considered

I have tried to define an empty path -

    '/provisioning/v2/things/v1/{thingId}':
        x-terraform-resource-name: things_v1

in the hopes that that would allow me to customise the parent resource's name, but it didn't work.

I also tried using x-terraform-field-name on the thingId path parameter in hopes of renaming the argument to thing_id, but the required input argument was still v1_id.

I have tried defining the parent resource and defining a custom resource name for the parent too, but that didn't change the output -

  /api/v2/things/v1:
    post:
      parameters:
        -
          name: body
          schema:
            $ref: '#/definitions/ThingV1'
          in: body
          required: true
      responses:
        '200':
          description: Create thing
          schema:
            $ref: '#/definitions/ThingV1'
    x-terraform-resource-name: things_v1
  '/api/v2/things/v1/{thingId}':
    get:
      responses:
        '200':
          description: Get thing
          schema:
            $ref: '#/definitions/ThingV1'
    parameters:
      -
        name: thingId
        in: path
        required: true
        type: string

.....
.....
definitions:
  ThingV1:
    description: ''
    required:
      - status
    type: object
    properties:
      id:
        description: ''
        type: string
        readOnly: true
      status:
        description: ''
        type: string

Checklist (for admin only)

Don't forget to go through the checklist to make sure the issue is created properly: