-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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 'resources' reading and 'location_id' setting on Firebase Project #3319
Add 'resources' reading and 'location_id' setting on Firebase Project #3319
Conversation
==> Checking source code against gofmt... |
Hello! I am a robot who works on Magic Modules PRs. I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review. Thanks for your contribution! A human will be with you soon. @rileykarson, please review this PR or find an appropriate assignee. |
@chrisst: Assigning review to you for your domain context, feel free to send back to me if needed and I can look deeper into it. |
7f0dc0e
to
d14a641
Compare
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.
Thank you for the contribution!
First of all there is a lot going on in this PR, so I would prefer if you were able to break it up a bit. The extra output fields are a pretty straight forward PR and could be merged in quickly.
I avoided adding the finalizeLocation API support because it's a singleton API with that is irreversible. It's worth putting in it's own PR at minimum and probably it's own resource. We often split resources apart when there are multiple endpoints on a single API with different payloads or different update logic. This allows us to keep custom code to a minimum which makes for more maintainable resources. We refer to these as "fine grained" resources.
I've added some quick thoughts as well so that we can reduce the number of round trips on this PR.
func dataSourceGoogleFirebaseProject() *schema.Resource { | ||
return &schema.Resource{ | ||
Read: resourceFirebaseProjectRead, | ||
Schema: map[string]*schema.Schema{ |
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.
We prefer to keep the datasource and resource schema as close as possible so we can use datasourceSchemaFromResourceSchema
to derive the schema instead of duplicating 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.
The schemas are actually identical other than "Compute/Optional/Required/Description". I didn't even realize there was a function that handled that. Do I just use that function to derive the schema or can the entire data source be generated?
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 mind splitting this into a separate PR if you'd prefer since it's really unrelated to adding the location_id.
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.
The function is just to derive the schema. But if it makes sense you can also just call through to the "read" method of the resource too. It can keep the datasource very small in terms of code and also updates to the resource such as new fields don't have to be replicated. A example of this is the compute router datasource
@@ -0,0 +1,57 @@ | |||
"resources": { |
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 understand why you have defined this schema both in the api.yaml and this extra schema. You should only need to define it in the api.yaml
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.
The issue is that the "location_id" is really a computed property of the Firebase Project. The only way to change this property is to call the separate "projectLocation:finalize" endpoint. Since I want the "location_id" property to be "Optional" in Terraform but never actually used on create, there is no way I can express that in the api.yaml.
The only way was to mark the property as output in the api yaml (as is the resources Array) and then in the terraform.yaml, exclude the resources property all together and define custom code for the schema.
return nil | ||
} | ||
transformed := make(map[string]interface{}) | ||
transformed["hosting_site"] = original["hostingSite"] |
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.
The generated flatteners should already handle the renaming of the fields. I don't think you should need a custom flattener at all.
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.
Unfortunately as stated above, if I mark the property as excluded in terraform.yaml, I had to define the flatteners in custom code. Those are actually the generated flatteners but just moved into custom code after I marked the resources property as excluded.
So at a high level, you're saying instead of making the special "location_id" property handling, I should just leave it as computed and create a separate "google_firebase_project_location" fine grained resource with a location_id and project properties? I assume that would of course be a separate PR entirely. If I do that, do you want the new output properties and the data source in two separate PRs or can those be combined and remain in this PR? |
At a high level - correct. This resource and datasource can continue to keep all the computed properties on them and just leave the location to be set by the new resource. I'm also happy to tackle this part if you don't have time. |
I think it's actually pretty straight forward if done that way (I don't know if there's even any custom code) so I think I can get it. I've actually moved on to implementing the Firebase WebApp with the goals of getting the config of the webapp (specifically the apiKey and authDomain) to send to Cloud Build so that it can be set as a substitution during the build. The issue is that the "Config" is retrieved via a separate single GET API call to a "/config" endpoint after creating the WebApp. I initially thought of creating a second resource WebAppConfig but realized that it would cause the generation of the associated resource when I only wanted a data source. I can't find a way of generating the "read" method of a resource without causing the provider.go to include it in the resources list. I have a few thoughts,
|
d14a641
to
039f029
Compare
Ok so I forced pushed a new commit that removes all the Project changes and instead creates a new fine grained "google_firebase_project_location" resource with a "location_id" property.
|
Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are. Diff report:Terraform Beta: Diff ( 6 files changed, 378 insertions(+), 6 deletions(-)) |
Removed the custom decoder and replaced with the "fine grain" resource operator "nested_query". Updated the import_id so that importing wouldn't crash terraform
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 looks way cleaner. I added a commit to take advantage of one of the lesser known features of magic modules that we added recently. Let me know if it makes sense and I'll merge this in. Thanks!
Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are. Diff report:Terraform Beta: Diff ( 6 files changed, 418 insertions(+), 6 deletions(-)) |
Looks great. Ty! |
…gleCloudPlatform#3319) * Add FirebaseLocation fine grained resource * Updates for firebase finalize location Removed the custom decoder and replaced with the "fine grain" resource operator "nested_query". Updated the import_id so that importing wouldn't crash terraform Co-authored-by: Chris Stephens <[email protected]>
Signed-off-by: Matt Morrissette [email protected]