-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
google_project_services creates dataproc-control.googleapis.com
without it being specified
#13004
Comments
Hey @mogronalol, I took a look at this and I don't have a good answer for you as to why this is happening :-/ I'm not able to reproduce it since I don't have permissions to create projects programmatically, and our tests that do so are passing just fine. Would you mind sharing a gist of the full debug output as specified in https://www.terraform.io/docs/internals/debugging.html? That might help. |
I get this exact same error as well as receiving one for the following:
For both the dataproc & containeranalysis services if I keep running terraform apply it finally goes through My complete list of services being enabled via terraform are as follows:
|
I just tried reproducing this myself, enabling only In doing so, apply worked fine, a follow-up plan yielded this:
I updated the config to use those services--which, presumably, Starting from the config with all those APIs enabled, a plan works as expected, and the apply gives me the forbidden error:
Here's the config I'm working with: resource "random_id" "id" {
byte_length = 4
prefix = "paddy-13004-"
}
resource "google_project" "project" {
project_id = "${random_id.id.hex}"
name = "Paddy 13004 Repro"
org_id = "{OUR ORG ID}"
billing_account = "{OUR BILLING ACCOUNT}"
}
resource "google_project_services" "project" {
project = "${google_project.project.id}"
services = [
"dataproc.googleapis.com",
"container.googleapis.com",
"compute-component.googleapis.com",
"deploymentmanager.googleapis.com",
"replicapool.googleapis.com",
"replicapoolupdater.googleapis.com",
"resourceviews.googleapis.com",
"storage-api.googleapis.com",
"storage-component.googleapis.com",
"dataproc-control.googleapis.com",
]
} Now that I've seen it in action, it looks like |
Unfortunately this isn't just isolated to the dataproc-control.googleapis.com service I enabled the containerregistry.googleapis.com service a moment ago and this brings with it the source.googleapis.com service so on a subsequent plan you receive a diff showing it being removed:
Obviously if you add the service at this point to your code it works fine but if you try to add this in the original plan/apply you receive the 403 error:
So this seems to affect at least the following that we know of:
Thanks, Joe |
Thanks for the additional information @joe-boyce. I'm going to look into compiling a list of the services this affects, and getting Terraform to just ignore them. The idea being that you can't manually add (or, presumably, remove) them, so Terraform shouldn't worry about drift (because it can't do anything about them, anyways). So the real issue is just getting them to not show up in the diff, which fortunately we have a tool for. I just need to figure out which APIs it needs to ignore. |
Thanks for the update, sound good! As you said the various services which can't be enabled/disabled are automatically enabled by other services anyway so they don't need to be referenced Thanks again, Joe |
The other problem is being 'private' which means you can't enable them at all through the API. Unfortunately I couldn't find documentation on the rules governing this on Google's side (At least that I could see), so I'm not sure how you are supposed to know which services meet this criteria. |
I'm trying to find out internally whether there are any others like this. However, ignoring services that can't be disabled only solves this in the case where you actively wish to disable the service. Some APIs enable other APIs (that we probably don't want to ignore) and will show a diff anyway. For example, I enabled just
We definitely don't want to ignore things like |
I see a similar issue. First apply:
Second apply:
Afterwards I'm good. The output above was created on a blank project where all services were enabled via terraform. I have a second project (which is now also managed by terraform) where we initially enabled some APIs through cloud console as well (I cannot recall exactly which ones) and only later introduced terraform to manage the APIs as well. On this second project I also have Unfortunately the whole Google API thing doesn't seem to be really well documented... So maybe somebody knows someone inside Google who can find out more about this mysterious behavior? 😉 |
@ctavan the
#2 is dangerous since that means the state file doesn't actually represent GCP state, so we're left with #1. As for the Google side of this, I can tell you that people are talking about it internally, but that's about all the detail I can go into. If you have specific places where you'd like more/better documentation (and an idea on how to make it better), I'm happy to file the appropriate issues. |
Hey @danawillow, #13730 is already a great improvement as it at least solve the most prominent problem of the apis which cannot even be manually created or deleted, so that's awesome! As for the other issue I think having to re-apply a second is acceptable since it only affects the very first apply and it's definitely better to have the correct representation of Google-side state in terraform. To me it appears that Google is pretty generous in choosing which APIs to auto-enable. For example I have no clue why So I think given #13730 we're all good now! Thank you for your work on this! |
BTW, does this mean that – given #13730 has been merged yesterday – can this issue be closed? |
Ah yes. Closing now! |
Great thanks Dana, look forward to when this is released! 👍 Cheers, Joe |
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Terraform Version
Terraform v0.9.1
Affected Resource(s)
Please list the resources as a list, for example:
Terraform Configuration Files
Debug Output
Expected Behavior
If I don't specify
dataproc-control.googleapis.com
anddataproc.googleapis.com
then it should not assign these services. If I do specify them then it should be able to create them.Actual Behavior
If I don't specify
dataproc-control.googleapis.com
anddataproc.googleapis.com
, then Google will still set them anyway. This means a subsequentplan
orapply
will do a diff, and think that I am removing these two services (Because they are present Google side, but not in the Terraform template, despite them never being specified). I then get a 403 when applying because it's not possible to disabledataproc-control.googleapis.com
, which is Terraform tries to do because it sees it as being removed.If I do specify
dataproc-control.googleapis.com
anddataproc.googleapis.com
, then I get 403 when applying because it's not possible to enabledataproc-control.googleapis.com
via an API call, which it Terraform tries to do. However I can run apply again, and it will work. This is because Google assigned it anyway, so a subsequent diff during plan will return no diff.Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform apply
terraform plan
// Notice Google has added these services, and Terraform thinks there is a diffThe text was updated successfully, but these errors were encountered: