soltysh
commented
3 years ago @ahmetb @corneliusweig I'm curious your opinions
Closed deejross closed 2 years ago
soltysh
commented
3 years ago @ahmetb @corneliusweig I'm curious your opinions
ahmetb
commented
3 years ago /kind proposal /area multi-index
Thanks for the proposal. The custom indexes right now are fairly under-utilized and we have limited understanding of how people use them in offline/air-gapped environments.
It would be fairly easy to come up with such an API. The relevant APIs we'd need are in go doc ./internal/index/indexscanner:
func LoadPluginByName(pluginsDir, pluginName string) (index.Plugin, error): GET /plugins/{NAME}func LoadPluginListFromFS(indexDir string) ([]index.Plugin, error): GET /pluginsHowever, the devil is likely in the details in this case. We had many edge cases when we implemented the custom indexes feature (how would we authenticate the user to a git repo, how would we authenticate the user while downloading files) and some of them are still not addressed (again, because we are not fully sure how people use it out in the wild).
Here are some arguments in my mind for allowing only git-based indexes:
I know implementing a git-remote just to serve plugin manifests can be quite an overkill, on the other hand, it's doable as well.
Perhaps a question for your proposal would be:
deejross
commented
3 years ago Thanks for your thoughts. To answer your questions:
what is the benefit of storing the index and the blobs in the cluster (as opposed to internet/intranet)?
With more k8s clusters being deployed to the edge, which are mostly disconnected, reducing the number of out-of-cluster resources and dependencies is greatly desired. For my use-case, the blobs are going to be stored in an image registry, which is already a dependency for k8s clusters. The index itself will be generated from k8s CRs.
what's the key benefit you get by serving over REST vs Git-HTTPS
Reduced complexity implementing a custom index. REST APIs are very easy to implement, git remote is not. Most implementations I've seen subprocess out to git for everything which is not ideal and could make deployments more challenging.
If you're lucky enough to have a git library implemented well-enough in your language of choice you can get around this (like I did in the prototype), but documentation for implementing a git remote in said library is likely non-existent. Even then, there's quite a lot of churn needed to create a repo, add, and commit files.
Another key benefit is authentication. With a REST API generating download links to itself, it can include additional identity/authentication/metadata information as part of the download URL in the form of JWTs or reference IDs. More on authenticating to the index itself below.
how would the kubectl machines (where Krew is installed) connect and authenticate to this cluster/server?
I think continuing to use the URL as configuration is sufficient. You currently set the URL with an environment variable for a custom index, and URLs can include basic auth information, if authentication is required. While basic auth with usernames/passwords is less than ideal, more advanced custom index implementations could use a more secure temporary token approach.
Hope that helps. Thanks.
k8s-triage-robot
commented
2 years ago 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:
lifecycle/stale is appliedlifecycle/stale was applied, lifecycle/rotten is appliedlifecycle/rotten was applied, the issue is closedYou can:
/remove-lifecycle stale/lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-triage-robot
commented
2 years ago 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:
lifecycle/stale is appliedlifecycle/stale was applied, lifecycle/rotten is appliedlifecycle/rotten was applied, the issue is closedYou can:
/remove-lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
k8s-triage-robot
commented
2 years ago 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:
lifecycle/stale is appliedlifecycle/stale was applied, lifecycle/rotten is appliedlifecycle/rotten was applied, the issue is closedYou can:
/reopen/remove-lifecycle rottenPlease send feedback to sig-contributor-experience at kubernetes/community.
/close
k8s-ci-robot
commented
2 years ago @k8s-triage-robot: Closing this issue.
Would there be any interest in supporting a REST-based index in addition to the Git-based index? In disconnected environments, a REST-based service could host the index and the binaries. This can reduce the amount and complexity of supporting infrastructure.
In a Kubernetes environment, images holding the desired binaries can be used instead of file servers and Git repos. In disconnected Kubernetes environments, you already have an image registry for the platform to pull from, so leveraging existing infrastructure is ideal. For the index itself, a custom resource definition could be created that would allow cluster admins to build a resource-based index.
The scope of this proposal is not to implement a CRD, controller, or service, but to define the REST API a controller would need to implement in order to build a custom krew index suitable for their environment. Once the API design is finalized, an API client for krew would then need to be implemented.
I have a working prototype of a controller that krew might consume via REST that can be found here: https://github.com/deejross/openshift-cli-manager
I recently implemented a krew-compatible interface via Git (not fully tested yet) on that controller, but this drove up complexity quite a bit and a recommendation was made to simplify it by suggesting that maybe krew should support REST APIs.