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.
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 #8125New resource
azurerm_mysql_server_key
- Add CMK support #8125Changes from 11 commits
c8b0ba7
fa4f3e3
b13adb5
39b460f
0dfa559
6699197
ecd0013
fc44b35
25cad7f
30ff395
9a482a0
369ac42
8df77e4
18fd376
e38d15d
5886baf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
presumably we'll also need to lock in the create/update/delete here too?
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.
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.
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.
so what happens if you try and decrypt the server and delete it simultaneously? a conflict will likely occur somewhere?
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.
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.
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.
can we test this to confirm?
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.
@ArcturusZhang any update here?
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.
Tests have been done per requested.