A case for provider input validation

[exitcode0]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

  ---

Context

The old input validation required maintenance whenever an upstream Okta API changed. This was unsustainable and (I believe) removing the feature was the right decision.

With that said, input validation is an important feature. It allows the Provider to identify errors earlier in the workflow during the Terraform Plan rather than later on during the Terraform Apply. Identifying mistakes earlier lets us spend more time working on solutions, improving efficiency and developer experience.

Proposal

The Okta Open API Spec v3(OASv3) presents us with an opportunity to implement a more sustainable approach to this feature. I propose that the Okta Provider or the Okta Go-Lang SDK use OASv3 as a reference point for input validation. This would (in theory) mean upstream Okta API changes would only necessitate we update the version of our OASv3 dependency.

I’m curious to head what the community and provider maintainers think of this suggestion 🙂

References

• OpenAPI initiative - openapis.org
• Okta Open API Spec v3 - github.com

[monde]

We discussed this our last stand up, @exitcode0 highlights the most relevant points about history, maintenance, etc..

One of our goals in v4 during the path to Okta TF v5 is to migrate all code from v2 okta-sdk-golang (now vendored as a local package in the sdk/ directory). As @exitcode0 points out, the OpenAPI code generator (https://openapi-generator.tech/) that generates code for v3 okta-sdk-golang does input validation. We thought we had avoided input validation but as noted v3 okta-sdk-golang brought it back through generated code.

@duytiennguyen-okta and I were thinking about "correcting" the code generation for okta-sdk-golang and rev'ing it as v4 . However, that is making more work, and I think the path of least resistance is to get Okta TF using 100% v3 otka-sdk-golang . This delegates input validation to v3 okta-sdk-golang which is generated from an OpenAPI spec.

Coincidently, I've picked up lead on Okta's internal OpenAPI spec and we have work scheduled to publish public facing artifacts for the spec to https://github.com/okta/okta-management-openapi-spec . Once this is underpinned with automation we can keep v3 okta-sdk-golang up to date in a timely fashion. Previously okta/okta-management-openapi-spec was curated by hand which would cause timely downstream updates to v2 okta-sdk-golang and Okta TF to be slowly rolled out.

cc @jefftaylor-okta