-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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 support in Helm builtin #4614
Conversation
@mikebz: This PR has multiple commits, and the default merge method is: merge. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Hi @mikebz. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/label tide/merge-method-squash |
This PR is probably more appropriate to make in this repo: https://github.com/kubernetes-sigs/krm-functions-registry/tree/main/krm-functions/sig-cli/render-helm-chart On the kustomize side, we have paused development on the helm plugin until we are able to migrate to the KRM function. The long term plan is here: #4401 and work is in progress on this front |
I am happy to add the work there as well, I would say there is a short term and longer term goals here. (1) - we should unblock customers who will use the builtin, (2) - we should migrate. |
/hold Having the test infra will be great, but it's also been pointed out to me that this is a hotfix for a particular use case. I'm designing a more general solution that we will put into the KRM function, after which we can see if we want to put it in the builtin plugin. But, this is a more substantial feature than I'd realized when I first saw this PR so I believe a better course of action would be to prioritize migration (which I plan to do this quarter). Again, the helm builtin is slated for deprecation and eventual removal, so our support on it is extremely limited. |
An update from the infra folks: The k8s infra doesn't yet properly support Artifact Registry, and they are hesitant to provision it for us ad-hoc for a single-cluster use case that the kustomize maintainers are skeptical about. It is more realistic for them to support it for us for the KRM functions registry a few months from now. |
Thanks for the update. One of the things to consider is that the current tests are hitting 3rd party chart registries. Maybe we can create one for functions and still use it for built in and the function. There is no precedent right now that all of the test repositories are CNCF owned. |
|
||
// OCI pull combine the repo and the chart name into one URL | ||
if strings.HasPrefix(p.Repo, "oci://") { | ||
chartUrl := p.Repo + "/" + p.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.
Just to clarify, it's saying Url
should be URL
in the variable name, I missed the distinction on first read-through.
Is it truly unacceptable to accept this patch as a stop-gap measure to unblock the user base of kustomize from using OCI registries? I agree the KRM function will be better long-term, but as it stands, the user base has to run external commands to pull OCI charts and make them available to kustomize locally before its invocation. Seeing as the helm team broke semver compliance, it stands to reason a hotfix should be acceptable to address the upstream products bad behavior. |
KRM functions aren't yet a viable replacement for built-in plugins. For instance, of the GitOps tools that support kustomize, which ones support KRM functions? Are there examples of executing KRM functions in CI? There was a suggestion to fork kustomize here: Since there are uses of the helm built-in plugin, I recommend continuing to support it until KRM function execution obstacles are overcome. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
Waiting for closed this issue 😁 |
I am guessing this addition is unwelcome. We have already created a workaround in ConfigSync, so my interest in lobbying for this more has waned :) |
i hope this issue can solving, because i need pull chart from oci repository |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
/retest |
@mikebz: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mikebz bump? |
/reopen |
@mikebz: Reopened this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mikebz: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: diegoluisi, mikebz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@diegoluisi @mikebz thank you for yours job done earlier. What next steps? It's not clear from last activity in thread. |
I think we need to clear go ahead from the project maintainers @KnVerey |
@mikebz can I help something? Also I did PR with fix lint alert: https://github.com/mikebz/kustomize/pull/1/files |
Thank you @antonydevanchi ! There are a few things to do to get this PR back into shape. I think the major question is whether we introduce a potential breaking change or not. |
@KnVerey and I discussed this, and the primary concern we have is a lack of bandwidth. There are a few things we need to address here, one of which is auth.
I believe this is because of kustomize's foundational principle that the kustomization file should not depend on its environment, which includes that it should not be able to get auth information from its environment. Breaking this encapsulation by allowing the user to run Because of that, the kustomize maintainers can't accept this PR as it is. OCI support in the Helm builtin then requires more thoughtful design, in particular how to properly do auth. As such, I think it would need a kustomize mini-KEP. For transparency, there are only 3-4 people working on kustomize, most of whom are spending less than 10% of their time on it. We are trying to prioritize things that are core to kustomize functionality, and additionally, none of us are particularly familiar with helm. We already have a large number of open PRs and one open KEP that we are struggling to find time to review, and as a result, we cannot promise that we have the bandwidth to support this feature. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
If this is truly the case, kustomize needs to break the ability to support network references that are fetched at build time, making the tool far less valuable when external network resources for kustomizations and helm charts can no longer be referenced, which by necessity are build time side-effects of a network fetch at a point in time. |
so sad |
This is currently WIP.
fixes: #4381
Questions for owner: @natasha41575 @yuwenma @KnVerey
It seems like @monopole has added environment variables to put the data and cache for HELM into a temp directory. Do we know why that is? The reason why this is undesirable with OCI is that most of the OCI repos are protected with auth. Auth is possible if one does authentication with Helm ahead of time. Example:
After that is run I am able to do things like:
and if the configuration is not in the temp location I can easily get the chart.
One of the ideas is to include some sort of an authentication in kustomization.yaml, but I think that would be undesirable.
Things that are left to figure out: