-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
azurerm_cdn_endpoint
- Standardize the resource ID to be case sensitive
#8237
azurerm_cdn_endpoint
- Standardize the resource ID to be case sensitive
#8237
Conversation
…tive This is a workaround for #Azure/azure-rest-api-specs#10576. Fixes: hashicorp#8191
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.
hey @magodo
Thanks for this PR - if we can add a couple of state migrations to patch the ID here then this otherwise LGTM 👍
Thanks!
@tombuildsstuff I have added the migration logic, thank you for the example link! |
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.
LGTM 👍
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.
Tests picked up a circular reference
@tombuildsstuff I have resolved the CI errors, PTAL! |
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.
Unfortunately due to the design of the new state migration functions we have to entirely duplicate the schema as a point-in-time copy - so we're unable to reuse this in the resource - incase this differs in the future
If we can duplicate that then this should otherwise be fine though 👍
return err | ||
}), | ||
|
||
Schema: tmpResource.Schema, |
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 schema needs to remain here - and be entirely duplicated for the migration; else if these differ in the future the original state migration schema is no longer valid - so unfortunately these cannot be reused and must be copy/pasted as a point-in-time reference to the current schema
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.
As this is a not a schema migration essentially, it is just the ID got migrated. I think it is fine to reuse the schema at this point.
If the schema got changed in the future, it should not impact the fact that the old ID format will be transitioned to the new one as long as the schema_version
in state is 0. On the other hand, if the schema introduced a breaking change and we want to keep backward compatibility, then we can do a point-in-time copy at that time (like a copy-on-write style).
In this way, it is like that the version 0 schema keeps evolving until we decide to snapshot it in a fixed version at the time that we really want to do some schema level migration.
What do you think?
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 state migration system assumes there's a fixed point-in-time schema (e.g. only these fields exist, so unfortunately any additions would be a breaking change). Whilst we could technically reuse this at this point - the amount of change in this codebase makes it plausable we could unintentionally introduce a breaking change later - so it's better to follow the convention used by other state migrations and duplicate this.
Whilst it's unfortunate the state migration system is designed to require a schema (and we've raised this with the Plugin SDK Team, since this shouldn't be necessary, or should only require the specific attributes being modified for deserialization/serialization) - duplicating this removes the possibility of these unintentional bugs here, which are going to be incredibly hard to capture.
As such we're better to duplicate this schema in both instances.
return err | ||
}), | ||
|
||
Schema: tmpResource.Schema, |
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 schema needs to remain here - and be entirely duplicated for the migration; else if these differ in the future the original state migration schema is no longer valid - so unfortunately these cannot be reused and must be copy/pasted as a point-in-time reference to the current schema
@tombuildsstuff I have added the dedicated PIT V0 schema as you suggested, please take another look! Thanks! |
azurerm_cnd_endpoint
- Standardize the resource ID to be case sensitiveazurerm_cdn_endpoint
- Standardize the resource ID to be case sensitive
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.
hey @magodo
Thanks for pushing those changes - I've taken a look through and left some more comments inline but if we can duplicate the remaining schema here (and remove the validation funcs since these are unnecessary) then this should otherwise be good 👍🏻
Thanks!
@tombuildsstuff Done, I also expand the function invocation for fields like |
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.
If we can make these consistent (these were missed in the last review cycle) then this otherwise LGTM 👍
@tombuildsstuff I have renamed the parameters, please take another look! |
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.
LGTM 👍
This has been released in version 2.26.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example: provider "azurerm" {
version = "~> 2.26.0"
}
# ... other configuration ... |
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
This is a workaround for #Azure/azure-rest-api-specs#10576.
Fixes: #8191
Test Result