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_mysql_server_key - Add CMK support #8125

Merged
merged 16 commits into from
Sep 22, 2020

Conversation

ArcturusZhang
Copy link
Contributor

Adding customer managed key support for mySQL server

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.

hey @ArcturusZhang

Thanks for this PR 👍

I've taken a look through and left some comments inline but this is looking good - if we can work through those then we should be able to take another look 👍

Thanks!

@@ -24,6 +24,10 @@ import (
"github.com/terraform-providers/terraform-provider-azurerm/azurerm/utils"
)

const (
mySQLServerResourceName = "azurerm_mysql_server"
)
Copy link
Contributor

Choose a reason for hiding this comment

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

presumably we'll also need to lock in the create/update/delete here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assume we do not need locks in postgresql server.

This key resource has a kind of weird behaviour - it is a separated resource from the server by service design, but it is a singleton, you could only have one key at one time. If you are trying to create two keys (with different name) for one server, after the second key is created on the service side, the first key will be automatically removed without any notice.

Therefore we need locks in the server key resource to ensure that if the user is not using this resource correctly (by say create two keys for one server), the order of key creation is predictable - this will always give the user a diff after apply.

The server does not have this kind of constraint, therefore I suppose the server resource does not need locks.

Copy link
Contributor

@tombuildsstuff tombuildsstuff Aug 25, 2020

Choose a reason for hiding this comment

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

so what happens if you try and decrypt the server and delete it simultaneously? a conflict will likely occur somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By decrypting the server, I assume we are deleting the server key - since we locked the server in the delete function of server key resource, we could not decrypt the server and delete it simultaneously - during the decrypting, the server is locked and deletion should hold on.

Copy link
Contributor

Choose a reason for hiding this comment

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

can we test this to confirm?

Copy link
Contributor

Choose a reason for hiding this comment

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

@ArcturusZhang any update here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tests have been done per requested.

@ArcturusZhang
Copy link
Contributor Author

Hi @tombuildsstuff I have made some changes, please have a look, thanks

Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

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

Thanks @ArcturusZhang - LGTM 🚀

@katbyte katbyte merged commit dd1fa9a into hashicorp:master Sep 22, 2020
katbyte added a commit that referenced this pull request Sep 22, 2020
@ArcturusZhang ArcturusZhang deleted the CMK-mySQL branch September 22, 2020 02:41
@ghost
Copy link

ghost commented Sep 24, 2020

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

@ghost
Copy link

ghost commented Oct 22, 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 👉 [email protected]. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Oct 22, 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.

4 participants