-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add the "google_compute_image" datasource #764
Conversation
@paddycarver Are you still working on a data source for image? |
Are there any updates on the status of this PR ? |
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.
Some preliminary feedback here. I'm mostly concerned about the design and the ergonomics of it, especially the the part about not being able to disable the project override on any image name that matches a set of semi-common strings, and the part about conflating family and image.
I dunno if it's helpful, but I do have a ~code complete version of this data source I've pushed here: https://github.com/terraform-providers/terraform-provider-google/blob/paddy_128_image_data_source/google/data_source_compute_image.go Feel free to use that for inspiration, or if you'd prefer, I'm happy to merge your documentation over to it and reuse the code and push forward with that one. I'm not wed to the code, though, so if you'd rather use your implementation as a base and continue iterating on it, I'm happy to do that, as well. :)
Thanks for contributing to Terraform, and my apologies for the long review delay!
google/image.go
Outdated
@@ -27,8 +28,12 @@ var ( | |||
resolveImageLink = regexp.MustCompile(fmt.Sprintf("^https://www.googleapis.com/compute/v1/projects/(%s)/global/images/(%s)", resolveImageProjectRegex, resolveImageImageRegex)) | |||
) | |||
|
|||
func fetchImage(c *Config, project, name string) (*compute.Image, error) { | |||
return c.clientCompute.Images.Get(project, name).Do() | |||
} |
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 not super-wild about the helper functions that wrap a single function call. This feels like it doesn't really add value over just calling the API directly. This definitely isn't worth blocking merge over, but if edits are needed anyways, maybe worth fixing while fixing other stuff.
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 agree on that too. No need to refactor one line of code into a function, i'll change that.
"name": &schema.Schema{ | ||
Type: schema.TypeString, | ||
Required: true, | ||
}, |
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.
Does it make more sense to make this optional, and have users enter names in the name attribute, or families in the family attribute? When we're specific like that, it can clear up some of the ambiguity.
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.
If you choose to declare a family it makes more sense.
builtInProject := findProjectFromBuiltinImage(name) | ||
|
||
if builtInProject != "" { | ||
project = builtInProject |
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.
As a user, how would I go about specifying an image of my own that shared a name with an image that has a builtin project? The way this is written, I think any image that has a family or image name containing "centos", "coreos", "debian", "opensuse", "rhel", "sles", "ubuntu", or "windows" will override the user-specified project with a hardcoded one, which will often not be the right thing to do, and I can't see a way around that behaviour at the moment. I see two potential fixes for this (there may be more):
- Establish a hierarchy. Project is an optional field, so we could check if project is empty, fall back on the built in project list if it is, and fall back on the provider project if we still don't know what to use.
- Make it explicit. Rather than inferring these built-in projects, users could just set the project for them, themselves.
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 agree with you on the second solution: making it explicit when choosing an image even a builtin one.
d.Set("size", image.DiskSizeGb) | ||
d.Set("self_link", image.SelfLink) | ||
d.Set("project", project) | ||
d.SetId(image.Name) |
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.
What happens if two resources are created with name
the same but project
different? Terraform would get confused, I think. We should probably embed the project in the ID, to make sure the ID is actually unique.
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.
You're right. i've noticed that you've used the ${family}/${name}
and forgot to prefix it with the project ID, i'll fix that also :)
If you don't mind, i'll merge your solution with mine and update this PR accordingly. |
Awesome! Looking forward to it. Excited to see this make it into the provider, and I'm really glad we got a chance to collaborate--I think merging our two approaches and having two sets of eyes on it will give us a really well-designed data source that works well for people. Thanks so much for the patience on this. |
da3f34d
to
0120a84
Compare
Changes done. Acceptance tests are working:
|
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.
Two incredibly minor documentation updates, and this looks good! If you don't get to them by Monday, I'll just take care of them. :)
|
||
```hcl | ||
data "google_compute_image" "my_image" { | ||
name = "image-family" |
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.
This seems misleading. Let's either do family = "image-family"
or name = "image-name"
|
||
* `self_link` - The URI of the resource. | ||
* `name` - The image name of the resource in case `family` was specified. | ||
* `family` - The family name of the resource in case `name` was specified. |
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.
These should both be set, regardless of which was specified, right?
I just pushed the doc fixes for this to a new branch, opened a new PR, and merged it, but keeping your commits intact. I didn't want your great work to get left out of another release over some documentation wording changes. Thanks so much for the patience and contributing this feature! |
i should definitively re-activate the notification! Thank you so much for your thorough review and your hints! It's great to see this datasource coming to the next release, it'll be really handy for my team to have that :) |
No worries at all, and sorry for jumping the gun on Friday instead of Monday. Please rest assured it is not a critique of your capabilities or timeliness, just a way to expedite this and make sure another release doesn't go out without it. :) Thanks so much for all the work you put into this, I think it's an amazing feature to add and something that has been on my backburner for a long, long time, and I'm really grateful you got to it and got it done. |
Thanks a lot for adding this! |
Signed-off-by: Modular Magician <magic-modules@google.com>
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 👉 hashibot-feedback@hashicorp.com. Thanks! |
We can't currently use custom images from other projects which is quite helpful in order to make "immutable" servers especially with the "family image" feature where we get the latest generated image (e.g. using
packer
) from a dedicated project.Acceptance result from this datasource:
The refactored "image" still pass the acceptance tests:
This closes #128.