-
Notifications
You must be signed in to change notification settings - Fork 548
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
Replaces gcloud commands by terraform resource #491
Replaces gcloud commands by terraform resource #491
Conversation
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.
Thanks for the PR and the work in the provider @thiagonache
I assume we can also get rid of the associated vars skip_gcloud_download
use_tf_google_credentials_env_var
etc and make this a breaking release. We would also need an upgrade guide to go along with it.
Great! I'll work on it soon. |
+1, this will need to be a breaking change w/ an upgrade guide which explains how to delete the |
…_default_service_accounts
I think we'll need to have another migrate.py script because just terraform state rm won't work. I may be missing something, but the state will change relatively as far as I can see. Can someone just give a second thought to make sure I'm not missing anything, please? @morgante @bharathkkb |
Please, hold on. I was missing one item (data) |
@thiagonache if you have an initial version of the upgrade guide, I am happy to test it. |
@bharathkkb you read my mind... just pushed it. still need to polish it btw |
did you get a chance to test it out? just wondering if you have any doubts. I've assumed that the new resource will be released on the next release (3.47). |
@thiagonache I have some concerns about this deleting all SAs which have the role on existing projects. IMO we should actually filter which SAs are deleted (as we do in the script). |
@morgante I'm not sure if I'm following. Are you talking about the upgrade guide? |
@thiagonache I will test it out soon, but looking at the instructions do we have to remove it from state manually? I don't see any gcloud destroy_cmd so it will be no-op. Without the manual |
Yes. Terraform crashes on the transform step trying to access the state
… On 5 Nov 2020, at 23:24, Bharath KKB ***@***.***> wrote:
@thiagonache I will test it out soon, but looking at the instructions do we have to remove it from state manually? I don't see any gcloud destroy_cmd so it will be no-op. Without the manual terraform state rm commands did it give an error when you tried to upgrade?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
On the provider we are just touching the default SAs. |
@thiagonache I tested out a simple upgrade and I did not need to directly make any changes to the statefile. # module.project-factory.module.project-factory.google_project_default_service_accounts.default_service_accounts will be created
+ resource "google_project_default_service_accounts" "default_service_accounts" {
+ action = "DISABLE"
+ id = (known after apply)
+ project = "project-id"
+ restore_policy = "REVERT"
+ service_accounts = (known after apply)
}
# module.project-factory.module.project-factory.module.gcloud_disable.null_resource.run_command[0] will be destroyed
- resource "null_resource" "run_command" {
- id = "5504134643976332785" -> null
- triggers = {
- "activated_apis" = "compute.googleapis.com,container.googleapis.com"
- "arguments" = "5cba1c8ef7cb6cc82509abf4392b5896"
- "create_cmd_body" = <<~EOT
--project_id='project-id' \
--sa_id='num-[email protected]' \
--credentials_path='' \
--impersonate-service-account='' \
--action='disable'
EOT
- "create_cmd_entrypoint" = ".terraform/modules/project-factory/modules/core_project_factory/scripts/modify-service-account.sh"
- "default_service_account" = "[email protected]"
- "gcloud_bin_abs_path" = "/google-cloud-sdk/bin"
- "md5" = "8724d44955a417594c942e0101e4fe82"
- "project_services" = "project-id"
} -> null
}
# module.project-factory.module.project-factory.module.gcloud_disable.null_resource.run_destroy_command[0] will be destroyed
- resource "null_resource" "run_destroy_command" {
- id = "1499773560248397990" -> null
- triggers = {
- "activated_apis" = "compute.googleapis.com,container.googleapis.com"
- "default_service_account" = "[email protected]"
- "destroy_cmd_body" = "info"
- "destroy_cmd_entrypoint" = "gcloud"
- "gcloud_bin_abs_path" = "/google-cloud-sdk/bin"
- "project_services" = "project-id"
} -> null
} |
It works, indeed. |
Maybe you're talking about passing the service account id (email). My understanding is since the documentation says SA is created only for two services (compute engine and app engine) and the e-mail may change, the best way to handle it is directly in the provider by service account name. There's a disclaimer in the resource documentation stating that. What I did not understand is why you said all SAs are being deleted... |
@morgante Please, let me know if we are in agreement or if you want to change this. |
@bharathkkb do you have any consideration/opinion about the discussion above? |
…erraform-google-project-factory into features/gcloud_dependency
@morgante sir, I've fixed my issue but we still have two errors:
It was added by you recently, wasn't? and
|
Yes, the whitespace issue was my mistake and I can fix. The test fixture issue is likely due to your upgrading the provider version, so you'll possibly need to update the network module version to remove the |
I believe network module was already fixed in the 2.0 release. @thiagonache can you try bumping it to the latest? |
you the man! |
@morgante @bharathkkb everything looks good on my side now. One thing I'm still not sure is if you guys agree with the approach of finding default service accounts. |
README.md
Outdated
@@ -122,7 +122,8 @@ determining that location is as follows: | |||
| budget\_amount | The amount to use for a budget alert | `number` | `null` | no | | |||
| budget\_monitoring\_notification\_channels | A list of monitoring notification channels in the form `[projects/{project_id}/notificationChannels/{channel_id}]`. A maximum of 5 channels are allowed. | `list(string)` | `[]` | no | | |||
| credentials\_path | Path to a service account credentials file with rights to run the Project Factory. If this file is absent Terraform will fall back to Application Default Credentials. | `string` | `""` | no | | |||
| default\_service\_account | Project default service account setting: can be one of `delete`, `deprivilege`, `disable`, or `keep`. | `string` | `"disable"` | no | | |||
| default\_sa\_restore\_policy | The action to be performed in the default service accounts on the resource destroy. Valid values are NONE and REVERT. If set to REVERT it will attempt to restore all default SAs but in the DEPRIVILEGE action. | `string` | `"REVERT"` | no | |
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 don't think we need to make this configurable.
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.
it must be... if we DELETE the service account, the resource won't be able to revert after 30 days. So, the user must change to NONE.
I proposed to keep track of when it was deleted and just try to undelete if less than 30 days, but Riley preferred to make configurable and change the value if error happens.
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.
It's fine for the behavior to be customizable on the provider, with the caveat that if set to "REVERT" I think the failure should not be an error (just a warning). /cc @rileykarson
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 disagree, I think. Terraform failing to do what you told it to (eg undeleting the deleted SAs) should result in an error. We could consider an additional option like "REVERT_AND_IGNORE_FAILURE" though.
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 think we can add another ENUM on_failure IGNORE or FAIL, but it would be an enhancement. I can work on it, but we should implement as-is for now.
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'm assuming you can work on a provider fix fairly quickly? We could also hold back this release until that's in.
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.
which I think is feasible unless something really bad happens.
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'll be able to work on it next week and should take no more than one day. So, yeah, it's not a biggy to merge like that... we will have the new version before 30 days for sure
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.
Sounds good!
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.
hashicorp/terraform-provider-google#7768 I still need to work on tests but we can start to discuss it
@morgante I've requested a review again since we cannot apply the last change requested. |
so, can we merge it? |
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.
Almost there.
No description provided.