-
Notifications
You must be signed in to change notification settings - Fork 187
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
OCI HelmRepository doesn't support charts at the root of AWS ECR #905
Comments
Thanks @bnsfrt for opening this PR. I think that you are correct in your analysis and we need to implement the missing parts to make this works for AWS ECR whether we provide a For the implementation part, it would be best to update the following function, so it can fallback to parsing a registry. The fallback option is preferred because |
Great! I'm glad to know I'm barking up the right tree. Would you like me to go ahead and take a crack at opening a PR for this change myself? |
that would be much appreciated. |
I've raised fluxcd/pkg#362 to address the issue and tested that the source-controller works with the change. |
Hello,
This issue is related to #896 and addresses what I believe may be a more proper fix for the problem.
As noted in #896, with
v0.29.0
deployed and a HelmRepository like the following created:the behavior we see is that the service panics due to an unhandled
nil
return, resulting from the failed parsing of the URL with the regex here.According to the documentation for HelmRepository objects of type oci, the URL is "expected to point to a registry repository." Based on this, I would expect that the proper configuration for a HelmRelease and HelmRepository referencing a chart in AWS ECR at
oci://<account>.dkr.ecr.<region>.amazonaws.com/<service>
would look something like this:In the above configuration the
HelmRepository
object is correctly pointing to the Helm repository where the chart is stored in ECR, and the.spec.chart
in theHelmRelease
object should effectively be redundant, as within a Helm repository there can be only one uniquely named chart. However, with this configuration, the source-controller appears to attempt to look up the<service>
chart using the URL from theHelmRepository
object as a base, generating an error like the following:The chart in question is located in AWS ECR at
oci://<account>.dkr.ecr.<region>.amazonaws.com/<service>
, so it is no surprise that the source-controller is unable to find any tags with the additional/<service>
appended on the path. This suggests that theHelmRepository
object is not actually referring, then, to a Helm repository properly, but rather to either an Helm registry or to a subpath within a Helm registry underneath which specific Helm repositories can be located. In either case, it is clear that the source-controller is expecting to be able to find the specific Helm charts in ECR at a path that involves appending/<.spec.chart>
to the URL from theHelmRepository
object.As a result of this finding, it appears that the only valid way to support a chart located at a path like
oci://<account>.dkr.ecr.<region>.amazonaws.com/<service>
would be for the URL in theHelmRepository
object to be set tooci://<account>.dkr.ecr.<region>.amazonaws.com
. However, as noted in #896 and as patched in #897 this URL is treated as invalid, because it does not successfully parse according to the regex built to parse and validate ECR images. The patch in #897 handles this case by returning an explicit error message declaring the failure to parse, effectively establishing that Helm charts housed in an AWS ECR repository that does not contain a/
character in the name are not to be supported by the source-controller.My request is one of the following (with a preference for the option number 1):
/([^:]+)
component optional? This would allow a URL likeoci://<account>.dkr.ecr.<region>.amazonaws.com
to pass and return the account and region properly to authenticate to AWS ECR. That enables the use of Helm charts located in ECR repositories without a/
character in their names, which I believe is a use case that should be supported.HelmRepository
objects of typeoci
do not properly correspond to a Helm repository, but rather a Helm registry or subpath within a Helm registry where Helm repositories may be located?I would be happy to contribute and test a solution if option number 1 is deemed desirable.
Thanks!
The text was updated successfully, but these errors were encountered: