Datasource for GCE service account #1119
Conversation
|
|
||
| func dataSourceGoogleComputeDefaultServiceAccount() *schema.Resource { | ||
| return &schema.Resource{ | ||
| Read: dataSourceGoogleComputeDefaultServiceAccountRead, |
There was a problem hiding this comment.
Could you add an optional project field to the schema? This way, users can find the default service account for projects that are not necessarily set as their default Terraform provider project.
There was a problem hiding this comment.
I think it's ready for another pass
|
|
||
| The following attributes are exported: | ||
|
|
||
| * `id` - Email address of the default service account used by VMs running in this project |
There was a problem hiding this comment.
Add a field named service_account in the schema instead.
There was a problem hiding this comment.
I can do that, but the data source itself is named data "google_compute_default_service_account". Does it make sense to add a field "service_account"? "google_compute_default_service_account.service_account" seems a little repetitive to me
There was a problem hiding this comment.
@danawillow what are your thoughts on this?
To give you some context. The DefaultServiceAccount is retrieved by calling the compute Project GET API. Our google_project data source is getting the project details from the resource manager GET API. The response does not include the DefaultServiceAccount.
I see different options:
- Create a
google_compute_default_service_accountresource (this PR). In that case, do we only set the id field or do we call the field a different name (e.g. service_account)? - Create a new resource to get all the compute GET API project details. In addition to the DefaultServiceAccount, we can also get the quotas, enabledFeatures and commoninstancemetadata. But how do we call this data source since we already have one for the resource manager GET API called
google_project? - Make a call to the compute GET API in the project data source and include the data there.
There was a problem hiding this comment.
- Interpolating based on ids isn't a good idea, since we've had many examples of changing ids for a resource over time. If we go with option one, then we should have it as a separate field even though it seems weird. In the
google_service_accountresource we have fields calledemailandaccount_id, so this one could match that. - If we did this, we could call it
google_compute_projectorgoogle_compute_project_info. I don't love either of those names, but metadata is a totally separate thing we can't call it that. - The thing that makes me a bit nervous about this is that the info the compute projects resource returns is compute specific. For example, the quotas it returns are only the GCE quotas. I don't know if that will ever change.
Right now I'm leaning towards option 1 (and then just have separate data sources for each item in the project resources as needed), but could definitely be persuaded that option 2 is the way to go.
There was a problem hiding this comment.
Thanks for your input Dana :)
I am also leaning towards option 1. To be consistent with the google_service_account resource, we should add a new field called email and set the default service account email to this field.
In the future, if users ask for the default service account id, we can add a new field called account_id to this google_compute_default_service_account data source and extract this value from the email.
There was a problem hiding this comment.
@rosbo @danawillow thanks for you input. I agree that having those to be consistent is a better approach. commit with the requested changes is on its way.
| Type: schema.TypeString, | ||
| Optional: true, | ||
| }, | ||
| "project_id": { |
There was a problem hiding this comment.
For consistency with all the other resource, could you rename this field "project"
| return err | ||
| } | ||
|
|
||
| if v, ok := d.GetOk("project_id"); ok { |
There was a problem hiding this comment.
the getProject method checks first if the "project" field is set and then fallback on the default provider project. This means you won't need this check here.
|
|
||
| The following arguments are supported: | ||
|
|
||
| * `project_id` - (Optional) The project ID. If it is not provided, the provider project is used. |
|
Merged! Thank you @ishashchuk for your contribution :) |
* Data source for retrieving GCE service account * Added project id for service account lookups (hashicorp#15) * Renaming attribute project_id -> project
* Data source for retrieving GCE service account * Added project id for service account lookups (#15) * Renaming attribute project_id -> project
|
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
locked and limited conversation to collaborators
Fixes #1104