Skip to content
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/resource_arm_storage_blob.go: make sure storage blob is read after create/update to update all the computed properties #4452

Merged
merged 1 commit into from
Sep 30, 2019

Conversation

abhinavdahiya
Copy link
Contributor

@abhinavdahiya abhinavdahiya commented Sep 27, 2019

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, 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

…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
@ghost ghost added the size/XS label Sep 27, 2019
@abhinavdahiya abhinavdahiya changed the title zurerm/resource_arm_storage_blob.go: make sure storage blob is read after create/update to update all the computed properties azurerm/resource_arm_storage_blob.go: make sure storage blob is read after create/update to update all the computed properties Sep 27, 2019
Copy link
Contributor

@tombuildsstuff tombuildsstuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thanks for this @abhinavdahiya

@tombuildsstuff
Copy link
Contributor

Tests pass:

Screenshot 2019-09-30 at 07 56 31

@tombuildsstuff tombuildsstuff merged commit e46e971 into hashicorp:master Sep 30, 2019
tombuildsstuff added a commit that referenced this pull request Sep 30, 2019
@ghost
Copy link

ghost commented Oct 4, 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
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)
@ghost
Copy link

ghost commented Mar 29, 2020

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 ghost locked and limited conversation to collaborators Mar 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants