-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Nested Structures in OpenAPI definitions #108
Labels
Comments
@dikhan, I can't actually apply the Project or Labels due to permission constraints :( |
Hi @chrised , thanks for raising this issue! I went ahead and added the labels, didn't realize they were not public. I updated the project roadmap to include this item and will let you know when we kick it off. |
dikhan
added a commit
that referenced
this issue
Aug 21, 2019
- Added support for nested structs ((#108)[#108]). More info (here)[https://github.com/dikhan/terraform-provider-openapi/blob/master/docs/how_to.md#object-with-nested-objects] - Added support for sub-resource ((#129)[#129]). More info (here)[https://github.com/dikhan/terraform-provider-openapi/blob/master/docs/how_to_subresources.md] - [Bug Fix] (#140)[#140]: When there is naming collision between resource, the provider behaves indeterminately - [Bug Fix] (#137)[#137]: For resources that are multi-region but the host is not correct the error returned is being ignored resulting into a resource configured with the wrong configuration. - [Bug Fix] (#130)[#130]: Fixed erratic behaviour where given a swagger file with no global http schemes defined the open api provider would default to http. Instead, the provider should work purely based on the openapi doc, and if it's missing http schemes containing supported protocols like http/https then the provider now fails to let the service provider know about it.
devstar0826
added a commit
to devstar0826/terraform-provider-openapi
that referenced
this issue
Oct 24, 2019
- Added support for nested structs ((#108)[dikhan/terraform-provider-openapi#108]). More info (here)[https://github.com/dikhan/terraform-provider-openapi/blob/master/docs/how_to.md#object-with-nested-objects] - Added support for sub-resource ((#129)[dikhan/terraform-provider-openapi#129]). More info (here)[https://github.com/dikhan/terraform-provider-openapi/blob/master/docs/how_to_subresources.md] - [Bug Fix] (#140)[dikhan/terraform-provider-openapi#140]: When there is naming collision between resource, the provider behaves indeterminately - [Bug Fix] (#137)[dikhan/terraform-provider-openapi#137]: For resources that are multi-region but the host is not correct the error returned is being ignored resulting into a resource configured with the wrong configuration. - [Bug Fix] (#130)[dikhan/terraform-provider-openapi#130]: Fixed erratic behaviour where given a swagger file with no global http schemes defined the open api provider would default to http. Instead, the provider should work purely based on the openapi doc, and if it's missing http schemes containing supported protocols like http/https then the provider now fails to let the service provider know about it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem?
We would like support for Nested Structures in our API Spec. This is currently supported by OpenAPI, but the plugin lacks support for it.
As far as I'm aware, this is possible within Terraform, but requires some workarounds until the 0.12 API/SDK takes over fully. See: https://github.com/hashicorp/terraform/issues/21217
Acceptance criteria
Support for nested structures in OpenAPI definitions.
Describe alternatives you've considered
We currently have this implemented at the top-level as multiple fields, but doesn't provide us any forward compatibility if we were to add additional similar structures, which abide by different names.
Additional context
Example structure for compatibility:
Checklist
Don't forget to go through the checklist to make sure the issue is created properly:
The text was updated successfully, but these errors were encountered: