Question and Issue related to terraform generation

[dicolanl]

Q: How do you configure the OpenAPI so that the terraform provider maps to a name? eg like we want the provider to be our company name. It appears its just creating it as "terraform".

Issue: I am testing with just 1 api as i try the CLI out for terraform. The API is a create. All APIs are configured with:

security:
        - api_key: []

after generation via CLI. if i run go generate it errors

internal/provider/inboundallowrule_resource.go:1970:70: not enough arguments in call to r.client.RulesInboundAllow.InboundAllowRulesCreate
    have (context.Context, shared.RuleBody)
    want (context.Context, shared.RuleBody, operations.InboundAllowRulesCreateSecurity)

looks like the generation create the call without the security?

res, err := r.client.RulesInboundAllow.InboundAllowRulesCreate(ctx, request)

Do you need to mark the securityScheme with some x-speakeasy annotation?

[dicolanl]

forgot add another Q.

I have an object for creation that has an array like

portsList:
      type: array
      items:
        type: object
        properties:
          ports:
            type: string
          protocolType:
            $ref: '#/components/schemas/protocol'

In the sample resource.tf that is created this is flattened to just ports = and protocol = and not portsList =[] is that expected?

[ThomasRooney]

How do you configure the OpenAPI so that the terraform provider maps to a name

Look for a .speakeasy/gen.yaml file after generation. Change the authorName / packageName to control this. We should auto-generate this config file with the defaults so you can see what to change. There’s a little documentation on gen.yaml options in our main docs site.

I am testing with just 1 api as i try the CLI out for terraform. The API is a create. All APIs are configured with:

In terraform all security needs to be defined at the global scope. I.e. a “security” tag at the root level of the OpenAPI spec. This is because it doesn’t make sense to allow non-provider-level security. Apologies that there’s not a linting rule to make this obvious; this is a gap I’ll close. We usually use an OpenAPI overlay file to delete operation-level-security / hoist it up to the global level.

In the sample resource.tf that is created this is flattened to just ports = and protocol = and not portsList =[] is that expected?

this is expected when Hoisting. I.e. ensure you set an “x-speakeasy-entity” tag at the root JSON schema of the request/response bodies, which effectively turns off hosting and gives you the behaviour you probably expect with the portsList attribute being a List of nested objects with ports/protocolType children. We have this (admittedly slightly odd) behaviour because:

1. We support Batch / list APIs to be used for single-resource-operations: inferring singleton usages of array elements when hoisting.
2. We struggle to build inference logic that works for all API shapes: so generally require these “hints” to do something that seems sensible.

Note: please do join our Slack and you’ll likely get a response a little faster. We’ve got a lot of flexibility in config options to make our output more sensible for different OpenAPI shapes.

[dicolanl]

Very detailed response thanks. I’ll find the slack and join.

Let me try a few things and come back now that I am armed with this knowledge?

[dicolanl]

closing.
1 & 2 worked. will go to slack for the array one