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

Replaces gcloud commands by terraform resource #491

Merged
merged 20 commits into from
Nov 10, 2020
Merged

Replaces gcloud commands by terraform resource #491

merged 20 commits into from
Nov 10, 2020

Conversation

thiagonache
Copy link
Contributor

No description provided.

@thiagonache thiagonache mentioned this pull request Nov 3, 2020
2 tasks
Copy link
Member

@bharathkkb bharathkkb left a 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.

@thiagonache
Copy link
Contributor Author

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.

@morgante
Copy link
Contributor

morgante commented Nov 3, 2020

+1, this will need to be a breaking change w/ an upgrade guide which explains how to delete the gcloud local-exec resources entirely.

@thiagonache
Copy link
Contributor Author

thiagonache commented Nov 5, 2020

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

@thiagonache
Copy link
Contributor Author

Please, hold on. I was missing one item (data)

@bharathkkb
Copy link
Member

@thiagonache if you have an initial version of the upgrade guide, I am happy to test it.

@thiagonache
Copy link
Contributor Author

thiagonache commented Nov 5, 2020

@bharathkkb you read my mind... just pushed it. still need to polish it btw

@thiagonache
Copy link
Contributor Author

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).

@morgante
Copy link
Contributor

morgante commented Nov 5, 2020

@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).

@thiagonache
Copy link
Contributor Author

@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?

@bharathkkb
Copy link
Member

@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?

@thiagonache
Copy link
Contributor Author

thiagonache commented Nov 6, 2020 via email

@thiagonache
Copy link
Contributor Author

@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?

On the provider we are just touching the default SAs.

@bharathkkb
Copy link
Member

@thiagonache I tested out a simple upgrade and I did not need to directly make any changes to the statefile.
My diff with initial skip_gcloud=true is below and it also worked false. What error did you observe?

  # 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
    }

@thiagonache
Copy link
Contributor Author

thiagonache commented Nov 6, 2020

It works, indeed.
After investigating I've found that the symlink I've created for the beta provider was pointing to the non beta provider 🤦
So I think we should add a note to upgrade the default_service_account to upper case if it is set somewhere.
Thank you for your support.

@thiagonache
Copy link
Contributor Author

thiagonache commented Nov 6, 2020

@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?

On the provider we are just touching the default SAs.

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...
Also, to include a new service account is just about three lines of code in the provider. I'm not anticipating that changing multiple times, are you?

@thiagonache
Copy link
Contributor Author

@morgante Please, let me know if we are in agreement or if you want to change this.

@thiagonache
Copy link
Contributor Author

@bharathkkb do you have any consideration/opinion about the discussion above?

@thiagonache
Copy link
Contributor Author

@morgante sir, I've fixed my issue but we still have two errors:

Checking for trailing whitespace
./helpers/setup-sa.sh:226:  
Error: Trailing whitespace found in the lines above.

It was added by you recently, wasn't?

and

terraform_validate ./test/fixtures/full 

Error: Unsupported argument

  on .terraform/modules/vpc/main.tf line 58, in resource "google_compute_subnetwork" "subnetwork":
  58:   enable_flow_logs         = lookup(var.subnets[count.index], "subnet_flow_logs", "false")

@morgante
Copy link
Contributor

morgante commented Nov 9, 2020

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 enable_flow_logs variable.

@bharathkkb
Copy link
Member

I believe network module was already fixed in the 2.0 release. @thiagonache can you try bumping it to the latest?

@thiagonache
Copy link
Contributor Author

I believe network module was already fixed in the 2.0 release. @thiagonache can you try bumping it to the latest?

you the man!

@thiagonache
Copy link
Contributor Author

@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 |
Copy link
Contributor

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.

Copy link
Contributor Author

@thiagonache thiagonache Nov 9, 2020

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.

Copy link
Contributor

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

Copy link
Contributor

@rileykarson rileykarson Nov 9, 2020

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.

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

Copy link
Contributor

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.

Copy link
Contributor Author

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.

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good!

Copy link
Contributor Author

@thiagonache thiagonache Nov 10, 2020

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

@thiagonache thiagonache requested a review from morgante November 9, 2020 20:22
@thiagonache
Copy link
Contributor Author

@morgante I've requested a review again since we cannot apply the last change requested.

@thiagonache
Copy link
Contributor Author

so, can we merge it?

Copy link
Contributor

@morgante morgante left a comment

Choose a reason for hiding this comment

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

Almost there.

@thiagonache thiagonache requested a review from morgante November 10, 2020 02:27
morgante
morgante previously approved these changes Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants