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

New Resource: azurerm_app_configuration #4859

Merged
merged 23 commits into from
Dec 10, 2019

Conversation

brennerm
Copy link
Contributor

This PR adds the resource azurerm_app_configuration that allows creating, deleting and updating Azure App Configuration instances.

Related issue: #3514

@ghost ghost added the size/XL label Nov 12, 2019
@brennerm
Copy link
Contributor Author

Tests and documentation are missing as I would like to agree on the implementation first.

@brennerm
Copy link
Contributor Author

Has been validated with this Terraform config:

resource "azurerm_resource_group" "test" {
  name = "test"
  location = "West Europe"
}

resource "azurerm_app_configuration" "test" {
  name = "test"
  location = azurerm_resource_group.test.location
  resource_group_name = azurerm_resource_group.test.name
}

output "test" {
  value = azurerm_app_configuration.test
}

@ghost ghost added size/XXL dependencies and removed size/XL labels Nov 12, 2019
@brennerm brennerm marked this pull request as ready for review November 13, 2019 07:29
Copy link
Member

@mbfrahry mbfrahry left a comment

Choose a reason for hiding this comment

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

Hey @brennerm. This is a good start and I'm glad you asked for a design check before fleshing the rest of it out. I think moving the keys from TypeMap to TypeList is a must and then we need to add quite a few nil checks

azurerm/resource_arm_app_configuration.go Outdated Show resolved Hide resolved
azurerm/resource_arm_app_configuration.go Outdated Show resolved Hide resolved
azurerm/resource_arm_app_configuration.go Outdated Show resolved Hide resolved
azurerm/resource_arm_app_configuration.go Outdated Show resolved Hide resolved
azurerm/resource_arm_app_configuration.go Outdated Show resolved Hide resolved
@brennerm
Copy link
Contributor Author

@mbfrahry I have another branch adding a new data source to get a value from an App Configuration. Are you OK with me adding these changes to this PR as both use the same App Configuration client code? Otherwise I'd create a separate PR.

@mbfrahry
Copy link
Member

Hey @brennerm, adding it here should be fine

@brennerm
Copy link
Contributor Author

Done

Copy link
Member

@mbfrahry mbfrahry left a comment

Choose a reason for hiding this comment

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

Hey @brennerm, this is a good start but we're missing a test and doc for this. Also, do you updating with master to fix config.go

azurerm/data_source_app_configuration_value.go Outdated Show resolved Hide resolved
@ghost ghost added the documentation label Nov 18, 2019
@brennerm brennerm force-pushed the add-app-configuration-resource branch from 9b7db45 to 015480a Compare November 19, 2019 23:13
@brennerm
Copy link
Contributor Author

@mbfrahry Apparently Azure allows upgrading from the free to the standard SKU but downgrading is not supported. The API responds with the following response:
StatusCode=400 -- Original Error: Code="SkuDowngradeNotAllowed" Message="ErrorSkuDowngradeNotAllowed"

How do you normally handle this? Make changing the SKU create a new resource by default or do we allow an upgrade in-place and tell the user that downgrading is not supported?

@mbfrahry
Copy link
Member

Ohhh, that's a tricky one. We have a way to customize the diff of a resource depending on certain conditions but I don't think we should use that here.

The API leaves a clear enough message on what is going on when trying to downgrade a sku that a user could act on and deal with themselves. Force newing on our end might add more confusion since we wouldn't be able to leave as helpful of a message as the api about why we need to force new when downgrading.

I think leaving what to do in the hand of the user is fine here.

@ghost ghost removed the waiting-response label Nov 28, 2019
@katbyte
Copy link
Collaborator

katbyte commented Nov 28, 2019

@brennerm,

the tests are failing with:

------- Stdout: -------
=== RUN   TestAccAzureAppConfiguration_free
=== PAUSE TestAccAzureAppConfiguration_free
=== CONT  TestAccAzureAppConfiguration_free
--- FAIL: TestAccAzureAppConfiguration_free (135.92s)
    testing.go:569: Step 1 error: ImportStateVerify attributes not equivalent. Difference is shown below. Top is actual, bottom is expected.
        
        (map[string]string) {
        }
        
        
        (map[string]string) (len=1) {
         (string) (len=3) "sku": (string) (len=4) "free"
        }
        
FAIL

------- Stderr: -------
2019/11/28 19:40:38 [DEBUG] Registering Data Sources for "Compute"..
2019/11/28 19:40:38 [DEBUG] Registering Resources for "Compute"..

looks like you need to set the SKU on read

@katbyte katbyte added this to the v1.38.0 milestone Nov 28, 2019
@brennerm brennerm force-pushed the add-app-configuration-resource branch from be712d5 to 60eb5c4 Compare November 28, 2019 20:52
@brennerm
Copy link
Contributor Author

Should be fixed. 👍

@brennerm
Copy link
Contributor Author

The schema version could be set to 0 as this is the initial version of this resource, right?

Copy link
Member

@mbfrahry mbfrahry left a comment

Choose a reason for hiding this comment

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

Hey @brennerm. I took another pass through and the tests are passing but the nil check aren't quite right. I left a comment but let me know if that doesn't make sense


"primary_read_key": {
Type: schema.TypeList,
MaxItems: 1,
Copy link
Member

Choose a reason for hiding this comment

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

This can be removed as MaxItems is a validation check for what a user submits rather than a check that the api only returns 1 of this. This goes for MaxItems on the blocks down below as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just out of curiosity, I got this from resource_arm_kubernetes_cluster.go. Is there some reason why it's necessary there?

Copy link
Member

Choose a reason for hiding this comment

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

Not that I'm aware! It might just be a mistake. That validation is only checked against what a user submits not what the api returns.


values := resultPage.Values()
for _, value := range values {
if &value == nil {
Copy link
Member

Choose a reason for hiding this comment

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

Unfortunately, this isn't the right check for nil. value is actually fine in this case as it's just an APIKey but the individual attributes in an APIKey are pointers *. Those need to be nil checked before pointing to them

@tombuildsstuff tombuildsstuff modified the milestones: v1.38.0, v1.39.0 Dec 3, 2019
@mbfrahry
Copy link
Member

mbfrahry commented Dec 9, 2019

Hey @brennerm. That nil check still isn't quite right. We want to still set whatever variables we have access too. I went ahead and wrote what it should look like up and merged with master since there were some tricky conflicts but for some reason I can't commit my changes to your branch. I opened a PR on your end with master changes and my three commits on top. Apologies for all the changes coming in! brennerm#1

@brennerm
Copy link
Contributor Author

brennerm commented Dec 9, 2019

@mbfrahry Understand, thought we are going with the all or nothing approach and ignore incomplete access keys which probably shouldn't happen at all.

Copy link
Member

@mbfrahry mbfrahry left a comment

Choose a reason for hiding this comment

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

LGTM!

@mbfrahry mbfrahry changed the title add resource azurerm_app_configuration New Resource: azurerm_app_configuration Dec 10, 2019
@mbfrahry mbfrahry merged commit 4887819 into hashicorp:master Dec 10, 2019
@mbfrahry
Copy link
Member

Thanks for your patience here @brennerm. This should go out the door in the next release

mbfrahry added a commit that referenced this pull request Dec 10, 2019
@ghost
Copy link

ghost commented Dec 16, 2019

This has been released in version 1.39.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.39.0"
}
# ... other configuration ...


---

# azurerm_container_registry
Copy link

@devblackops devblackops Dec 16, 2019

Choose a reason for hiding this comment

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

Copy/paste error here? This should be # azurerm_app_configuration

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct, fixed with #5186.

@ghost
Copy link

ghost commented Jan 10, 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 Jan 10, 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.

5 participants