-
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
automanage
: refactoring to use hashicorp/go-azure-sdk
#25293
Conversation
internal/services/automanage/migration/configuration_v0_to_v1.go
Outdated
Show resolved
Hide resolved
internal/services/automanage/migration/configuration_v0_to_v1.go
Outdated
Show resolved
Hide resolved
internal/services/automanage/migration/configuration_v0_to_v1.go
Outdated
Show resolved
Hide resolved
Hi @tombuildsstuff the tests failure are probably due to the lack of permission from test subscription. You could enable this feature flag by following steps in #22799. Local test on the original code:
|
@liuwuliuyun in our case those features aren't registered, so that makes sense - however the API returns this rather cryptic when the feature isn't enabled:
Whereas previously (from #22799) it returned the much more helpful:
As such given the documentation doesn't show this - would you mind adding documentation to highlight that this is needed? Thanks! |
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.
There are still MaxItems
attributes in the schema for the state migration but otherwise LGTM 👍
d780ae3
to
bb0ea73
Compare
…zure-sdk` incl. state migration
…rp/go-azure-sdk`
…dk/automanage/2022-05-04`
bb0ea73
to
3e77d2f
Compare
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Community Note
Description
This PR updates the
automanage
service package to usehashicorp/go-azure-sdk
rather thantombuildsstuff/kermit
.During this migration I've discovered that the
AzureStackHCI Cluster
resource is unexpectedly managing the association between the AzureStackHCI Cluster and the associated AutoManage Configuration, rather than exposing this association as separate resource (as this should be) - as such I've added TODOs for us to fix this in 4.0.Unfortunately it appears that despite the Service Team committing that there would be no breaking changes to the payload (specifically that any changes would be additive) - there's been a breaking change to the payload since the original pull request was merged - given that the
TestAccAutoManageConfigurationProfile_complete
andTestAccAutoManageConfigurationProfile_update
tests haven't passed for some time.As such - @liuwuliuyun / @mybayern1974 can you please reach out to the Service Team to find out what's happened here?