azurerm/resource_arm_storage_blob.go: make sure storage blob is read after create/update to update all the computed properties #4452
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…fter create/update to update all the computed properties The previous behavior of the create was to read the resource like almost all others to make sure the computed properties like `url` are set. but with the change [1], it was changed to update to make sure create was done correctly, but update doesn't have a read call making the create failing to set the `url` property [1]: hashicorp@cab451f#diff-8e833d66ec7540aaf7ec57fd375ba62aR177-R178
abhinavdahiya
changed the title
tombuildsstuff
approved these changes
Sep 30, 2019
|
Tests pass:
|
tombuildsstuff
added a commit
that referenced
this pull request
Sep 30, 2019
|
This has been released in version 1.35.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 = "~> 1.35.0"
}
# ... other configuration ... |
abhinavdahiya
added a commit
to abhinavdahiya/installer
that referenced
this pull request
Oct 8, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
abhinavdahiya
added a commit
to abhinavdahiya/installer
that referenced
this pull request
Oct 8, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
abhinavdahiya
added a commit
to abhinavdahiya/installer
that referenced
this pull request
Oct 8, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
abhinavdahiya
added a commit
to abhinavdahiya/installer
that referenced
this pull request
Oct 8, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
alaypatel07
pushed a commit
to alaypatel07/installer
that referenced
this pull request
Nov 13, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
jhixson74
pushed a commit
to jhixson74/installer
that referenced
this pull request
Dec 6, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
jhixson74
pushed a commit
to jhixson74/installer
that referenced
this pull request
Dec 16, 2019
…ndle private_dns zone
Using the upstream azurerm provider is not possible for now because of following reasons:
1) There is not srv record resource for private dns zone
2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
* hashicorp/terraform-provider-azurerm#4452
* hashicorp/terraform-provider-azurerm#4453
* hashicorp/terraform-provider-azurerm#4501
Some of these bugs are fixed, and some are in flight.
Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
`standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
`panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`
Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere
A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.
[1]: hashicorp/terraform-provider-azurerm#4474
(cherry picked from commit af00810)
|
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 👉 hashibot-feedback@hashicorp.com. Thanks! |
ghost
locked and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The previous behavior of the create was to read the resource like almost all others to make sure the computed properties like
urlare set.but with the change, it was changed to update to make sure create was done correctly, but update doesn't have a read call making the create failing to set the
urlproperty