Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
importer-rest-api-specs - Add Schema and Documentation Overrides #3610
importer-rest-api-specs - Add Schema and Documentation Overrides #3610
Changes from 8 commits
0ed6e19
453c089
492f8d2
961df1a
9122a0d
39e0bc8
c9d23ec
28dc353
a402718
532d0dd
3789afa
4650921
d7d677f
34aa2b0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I can't comment on the
Build
method since it's too far up, but assume this comment is there)Rather than adding the overrides to the
resourcemanager.TerraformResourceDetails
struct - it'd be worth passing in a secondary struct which contains any additional configuration for this resource (for now, being just the override data) - which allows these overrides to stay scoped to theimporter-rest-api-specs
tool - can we update this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After investigating, I don't agree with this.
The overrides that we specify are tied to a specific resource, in a specific version, in a specific service. Pulling them out of the
resourcemanager.TerraformResourceDetails
struct means we lose the information required to decide on what resource, in which version and service to apply the override.This update would require us to either nest this secondary struct containing the overrides within a resource, version, service struct or add metadata to the secondary struct containing resource, version, service to be able to determine to which resource/version/service an override applies to, in other words if I pull it out, I don't have to information to know which override information to pass into the
Build
method. I don't believe the overhead and complexity that this adds is worth the benefit of it remaining scoped toimporter-rest-api-specs
.I'm open to revisiting this when we discuss boundaries/separation of concerns for refactoring and making Pandora more manageable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the limitation (that I don't expect we'd change) that each Terraform Resource is tied to one specific API Version - therefore we’ve got the Service / API Version for each Resource (available in these types which come from the config files [where the
override
information will be defined]).Since we’re iterating over each resource, we’ve got access to the Service, API Version and Resource (Label) in question - so I think it should be possible to pull that out here, where we build up the Terraform Resource, Tests and Example Usage - for example:
Whilst the
TerraformResourceDetails
type is doing a little more than it should today - adding more information into this (and particularly persisting it to disk/the Data API) is going to dramatically increase the complexity down the line.As such I think we want to make a concerted effort to prevent this information from leaking outside of the
importer-rest-api-specs
tool for now - meaning that we need to ensure these fields aren’t included inTerraformResourceDetails
.Ultimately this ensures that the
importer-rest-api-specs
tool is the only thing concerned with the overrides - theTerraformResourceDetails
that's written to the API Definitions contains just the overridden result (e.g. the Terraform Resource with any overrides applied) meaning that other tools (Data API, Go SDK Generator etc) are unaware that any overrides have been applied - meaning they're focused on one thing (and doing one thing well).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than introducing a new method for this, if we reuse this method we should be able to support this across all fields, rather than just those we're building from within the Resource ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current implementation supports overrides for Resource IDs and nested fields, it doesn't for top level fields because this method that you linked isn't called for top level fields and by the looks of it shouldn't be for the moment since it's mainly hardcoding the field details and mappings for properties like location, zones, identity etc.
I disagree about reusing that method on the fields we source from the resource IDs, my reason is explained in point three of the PR description. As a compromise I've removed the schema overrides as a field processor, rewritten this function to
applySchemaOverrides
to do the overrides.applySchemaOverrides
is called both here and by the method linked in the paragraph above, so that nested fields can have overrides applied too.