-
Notifications
You must be signed in to change notification settings - Fork 80
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
Support storage HMAC key #261
Support storage HMAC key #261
Conversation
a54e42a
to
23bed65
Compare
/test-examples="examples/cloudplatform/storagehmackey.yaml" |
23bed65
to
98a58e1
Compare
Sorry, I couldn't see the failure because I was on vacation and GH Actions deleted the logs. Can you run it again? |
/test-examples="examples/cloudplatform/storagehmackey.yaml" |
Alright, I'll deploy a custom build on my cluster and test it there |
990f46a
to
f4ec683
Compare
I just tested the feature in my cluster. Worked well! The issue with the example was that the SA name was too long |
/test-examples="examples/cloudplatform/storagehmackey.yaml" |
It passed now. Anything for me to do about the breaking changes check? The |
f4ec683
to
2d1289c
Compare
Hi @julienduchesne, thank you for this PR. This PR has conflicts, I tried to rebase but I don't have access to |
Issue: crossplane-contrib#51 This resource is needed to do S3-style access on GCS buckets As this comment shows: crossplane-contrib#197 (comment), this resource causes an import cycle However, we can resolve that by putting the resource in the `cloudplatform` package. While, this key is specific to storage, it is still just a product of a service account and isn't linked to any storage resources. Signed-off-by: Julien Duchesne <[email protected]>
Signed-off-by: Julien Duchesne <[email protected]>
2d1289c
to
a5bb2aa
Compare
Done! |
/test-examples="examples/cloudplatform/storagehmackey.yaml" |
r.References["service_account_email"] = config.Reference{ | ||
Type: "ServiceAccount", | ||
Extractor: common.ExtractEmailFuncPath, |
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.
r.References["service_account_email"] = config.Reference{ | |
Type: "ServiceAccount", | |
Extractor: common.ExtractEmailFuncPath, | |
r.References["service_account_email"] = config.Reference{ | |
TerraformName: "google_service_account", | |
Extractor: `github.com/upbound/upjet/pkg/resource.ExtractParamPath("email",true)`, |
We have a function that we use for these cases. I think there is no need for an extra function here, the above configuration will suffice.
// ExtractEmailFuncPath holds the GCP resource email extractor func name | ||
ExtractEmailFuncPath = "github.com/upbound/provider-gcp/config/common.ExtractEmail()" |
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 can remove these lines.
|
||
// ExtractEmail extracts the value of `status.atProvider.email` | ||
// from a Terraformed resource. If mr is not a Terraformed | ||
// resource, returns an empty string. | ||
func ExtractEmail() reference.ExtractValueFn { | ||
return func(mg resource.Managed) string { | ||
paved, err := fieldpath.PaveObject(mg) | ||
if err != nil { | ||
return "" | ||
} | ||
r, err := paved.GetString("status.atProvider.email") | ||
if err != nil { | ||
return "" | ||
} | ||
return r | ||
} | ||
} |
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 can remove these lines.
// Avoid an import cycle, this is a key used for S3-style auth. It's meant to be used by end users, not other resources. | ||
"google_storage_hmac_key$": ReplaceGroupWords("cloudplatform", 0), |
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 verified that if we don't make a group change it causes an import cycle:
But I'm not sure if this is the right solution here. @ulucinar, @sergenyalcin what do you think about this?
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.
@turkenf as far as I understand, the reason of this import cycle is reference addition in the config file.
In the context of API groups, I don't think this is the right solution approach, since we depend on external providers' groups.
Until today, we have chosen the method of removing references in these cases. I am aware that this is not an ideal solution either, but in order to solve this problem in the long term, it is necessary to address it at the upjet level.
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.
@turkenf as far as I understand, the reason of this import cycle is reference addition in the config file.
@sergenyalcin in fact, even if no reference is defined in the config file, we encounter an import cycle error because the same resource is automatically injected with references.
We can reset it with the following configuration in config/storage/config.go
and in this case, we do not encounter an import cycle error:
p.AddResourceConfigurator("google_storage_hmac_key", func(r *config.Resource) {
r.References["service_account_email"] = config.Reference{}
})
Should we proceed this way?
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.
Emptying the reference does work. However, I have one issue. The service account email is made up of the SA name + the GCP project name. I do not have the latter, so I cannot create an example
Any way to fix that?
/test-examples="examples/cloudplatform/storagehmackey.yaml" |
I'm curious about the reason for closing this PR. Was it due to breaking changes or requiring a fix from an upstream dependency (upjet)? This feature seems very important for s3 api compatibility, which is essential for organizations that use both providers for their buckets. |
For those interested, I've submitted a new PR targeting this resource, see #546 |
Issue: #51
This resource is needed to do S3-style access on GCS buckets
As this comment shows: #197 (comment), this resource causes an import cycle
However, we can resolve that by putting the resource in the cloudplatform package.
While this key is specific to storage, it is still just a product of a service account and it isn't linked to any storage resources. It is meant to be used by end-users and not other resources