search

hashicorp / terraform-plugin-codegen-openapi

OpenAPI to Terraform Provider Code Generation Specification
Mozilla Public License 2.0
49 stars 6 forks source link

[Question] Does the current codegen framework generate http calls for scaffolded resources? #92

Closed drewmullen closed 7 months ago

drewmullen commented 8 months ago

We're experimenting with and excited about this new tech preview. After reading through the docs and walking through the workflow example (which worked great!) I'm not seeing any actual HTTP calls. We tried with another OAS doc that we want to create a provider for and had the same outcome.

Does the codegen framework currently generate HTTP calls or helper methods for the paths defined in the schemas? Based on the comment in the workflow example, I'm assuming no but I just wanted to make sure I'm not missing something.

// Typically this method would contain logic that makes an HTTP call to a remote API, and then stores
// computed results back to the data model. For example purposes, this function just sets computed Order
// values to mock values to avoid data consistency errors.
func callOrderAPI(ctx context.Context, order *datasource_order.OrderModel) diag.Diagnostics {

Thank you for this project - we're highly anticipating using it!

austinvalle commented 8 months ago

Hey there @drewmullen 👋🏻 ,

You're correct that the initial release of the tech preview was focused on schema generation (and the function you referenced in the workflow examples (callOrderAPI) was not generated, hand written by myself 😄 ). To be more specific, this tfplugingen-openapi generator currently implements most of the provider code specification, which currently doesn't contain any understanding of an API operation which could be generated by something like tfplugingen-framework.

We're currently in a discovery phase of trying to figure out the best way to model more "complete" provider code generation using this spec, which could potentially include information on how to call an API (headers, URLs, requests/responses, etc). If you have thoughts or feedback on modeling that information in the specification, you could open an issue in the https://github.com/hashicorp/terraform-plugin-codegen-spec repository.

We're also doing some discovery on how a provider developer may be able to utilize the tfplugingen-framework project to customize the output of the framework code generated (which only gives you schema right now), which wouldn't require the spec to contain this API operation implementation. This path might introduce custom Go templating (similar to terraform-plugin-docs) or maybe a Go module. If you have thoughts in that area, a good repo to file an issue would be over here: https://github.com/hashicorp/terraform-plugin-codegen-framework/

drewmullen commented 8 months ago

Hi @austinvalle Thank you for clarifying and for the background information. We'll continue to keep an eye on these projects!

Couple of questions...

I'm happy to move these questions to repos also - is this the kind of feedback / discussion yall are looking for? My problem is that I dont really understand the walls between the repos. Perhaps maybe a thread on https://discuss.hashicorp.com/ might help facilitate conversation?

austinvalle commented 8 months ago

I'm happy to move these questions to repos also - is this the kind of feedback / discussion yall are looking for? My problem is that I dont really understand the walls between the repos. Perhaps maybe a thread on https://discuss.hashicorp.com/ might help facilitate conversation?

This is great, we appreciate the thoughts as it helps us get a handle on what the community is thinking about. As for where to put these types of discussion/feedback items... I think it's a good idea to create a discuss forum thread as a "catch-all" for general feedback, I will create a thread and link it in our README/issue templates.

Do yall plan build a client that we can use?

I'm assuming that by "client" you mean a "wrapper" for all of the tools we introduced in the tech preview. We aren't actively building a "wrapping" client right now, but there isn't any restriction in the overall code generation design that prevents this type of client from being developed in the future.

When you generate the provider do you think the http logic will be built into the provider code base or will you abstract that into a generated SDK?

We haven't started designing it, but I'd imagine if we do generate an SDK it would be very lightweight and only intended to be used by the code generating the terraform provider. We're trying to avoid creating a generic Go API SDK generator (although that may not be possible to fully avoid 😆 )

How do you plan to handle resources that can only be described using a paginated list call + a human-friendly field? Thinking like, a data source where the id is not known... maybe you only have the name or some tags of the object youre querying for

That would need to be a consideration and modeled whenever we create the design of calling these APIs in the provider code spec, along with other problems like timeouts. Not sure I have a great answer for you right now other than, if we do build code generation that supports calling an API with pagination, we'll want to add it to the provider code spec so all source spec generators can take advantage of it (not just OpenAPI)

austinvalle commented 7 months ago

@drewmullen I configured our issue chooser on this repo (and the other code gen repos) to point to the Discuss forum for questions and feedback.

Feel free to create new topics over there if you have further questions and thoughts: https://discuss.hashicorp.com/c/terraform-providers/tf-plugin-sdk/43

Thanks!

github-actions[bot] commented 1 month ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.