Support for Any Type schema

[pauly4it]

Our OpenAPI spec contains quite a few Any Type/arbitrary-type schemas.

Currently, the codegen tool skips a resource in the generator config because one of the child schemas is an Any Type, returning the following message: time=2023-10-20T16:27:09.841-06:00 level=WARN msg="skipping resource schema mapping" resource=system oas_path=decision_mappings.allowed.expected oas_line_number=5019 err="no 'type' array or supported allOf, oneOf, anyOf constraint - attribute cannot be created"

Example:

systems.v1.AllowedMapping:
  properties:
    expected:
      $ref: '#/components/schemas/systems.v1.AllowedMapping.expected'
    negated:
      default: false
      description: when set to true, decision is Allowed when the mapped property IS NOT equal to the expected value
      type: boolean
    path:
      description: dot-separated decision property path
      type: string
  required:
    - path
systems.v1.AllowedMapping.expected: {}

In the above example from our spec, expected can by any type of value based on the user's custom configuration (e.g, true, 200, "allowed", {"allowed": true, "errors": null}, etc.).

[austinvalle]

Hey there @pauly4it 👋🏻 ,

To provide some initial expectations, there are a couple dependencies that we need to resolve before this functionality can be added to codegen-openapi:

• The provider code spec is based on Terraform Plugin Framework, which currently does not support a dynamic type. The design work for a "dynamic type" is currently in-progress and can be tracked in this issue: https://github.com/hashicorp/terraform-plugin-framework/issues/147
• The provider code spec will need to have this dynamic type introduced for resources/data sources/providers: https://github.com/hashicorp/terraform-plugin-codegen-spec/blob/main/resource/attribute.go#L74
• A code generation implementation will need to be added for this new Plugin Framework dynamic type: https://github.com/hashicorp/terraform-plugin-codegen-framework

Once those are in-place, adding this functionality to codegen-openapi will be possible and we can consider this enhancement. I'll add this issue to our backlog to track 👍🏻

[pauly4it]

@austinvalle could we potentially treat an Any Type as a string?

I was thinking more about how a user may configure that expected attribute from my example in a TF HCL file, and it could be something like:

resource "system" "example" {
  # ... other system resource config params

          expected = <<EOF
{"allowed": true, "errors": null}
EOF

  # ... rest of system resource config
}

[austinvalle]

Hmmm 🤔,

While it may be possible to represent this use-case of Any as a string, I'm not sure that'd be expected for all cases. I'm wondering if maybe in the future we could extend the overrides config block to allow explicitly setting the type.

data_sources:
  system:
    read:
      path: /system
      method: GET
    schema:
      attributes:
        overrides:
          expected:
            type: string

For what you described above, a string type would work, but you might even want to use the jsontypes.Normalized type, which is built on top of the string type: https://github.com/hashicorp/terraform-plugin-framework-jsontypes.

[pauly4it]

Overrides of attribute type would definitely help solve the problem in these types of cases. Combined with #81, it could add more flexibility into the configuration.

[bflad]

Good news here is that the first part of this, terraform-plugin-framework support for dynamic types and attributes is available. The other code generation projects will need to be updated with that support then hopefully this can be supported.