adding the enhancement for plugin discovery and download #41
Conversation
|
/cc @sseago |
There was a problem hiding this comment.
To make things a bit clearer for the first iteration (minimal) functionality, it might be worth providing a bit more detail as to how this enhancement would be used in the following two use cases (and if these cases are outside the scope here, then where will we handle that functionality):
- I have a binary plugin that I already know about. Perhaps a binary in a local directory, or perhaps a download URL for one from a crane-lib page somewhere -- i.e. one of the plugins with .go src code under crane-lib today
- I want to enable/disable the internal kubernetes plugin which is (hopefully) built into the crane executable, since it's not implemented as an external binary plugin.
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| I believe that we should follow a pattern like [krew index](https://github.com/kubernetes-sigs/krew-index). I believe that we do not have to start with the full type. For now we will have a smaller subset of fields. We will make sure of github releases and create a new folder called crane-index in the crane repo. This will be baked into the crane CLI for start. We will in a follow on enhancement allow for folks to provide their own indexes. |
There was a problem hiding this comment.
out of curiosity, what could be some of the reasons for providing a separate index?
NIT: some alternatives to crane-index name could be transforms-index or simply plugins-index?
There was a problem hiding this comment.
Also for clarity, I wonder if we should add a sample release content?
There was a problem hiding this comment.
My 2 cents: I like crane-index over the suggestions.
There was a problem hiding this comment.
I'm seeing some parallels here with the OLM catalogs (redhat-operators vs. community-operators). It feels like we'll end up wanting something similar. WDYT about including a section exploring how we expect to expose RH certified plugins vs. community plugins?
Another question: how do we expect to distribute these plugins? Are they distributed in pre-built binary form (that's what the Arch col suggests as part of discovery)? Or is it a series of pointers to github repos that build on the user's machine?
Maybe the binaries are distributed on images and exported?
I'm very excited to see this being considered so early; this is a major feature that really expands the usefulness of the tool and opens up some very cool opportunities. Thank you for starting the conversation @shawn-hurley
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| I believe that we should follow a pattern like [krew index](https://github.com/kubernetes-sigs/krew-index). I believe that we do not have to start with the full type. For now we will have a smaller subset of fields. We will make sure of github releases and create a new folder called crane-index in the crane repo. This will be baked into the crane CLI for start. We will in a follow on enhancement allow for folks to provide their own indexes. |
There was a problem hiding this comment.
My 2 cents: I like crane-index over the suggestions.
|
|
||
| ##### List Command | ||
| ```sh | ||
| $ crane plugin-manager list |
There was a problem hiding this comment.
Alt suggestion: crane plugin <op>. manager here feels unecessary, other tools come to mind like vagrant plugin. That's about as far as I want to go modeling that tool, however :)
There was a problem hiding this comment.
maybe we need to map that out further, I think that the problem is that I want a command for listing plugins that are currently available on disk AND a command to get the list from a given index.
I thought that maybe this made sense as plugin subcommand would be for on disk, and plugin-manager would be for anything related to the index. Thougths?
There was a problem hiding this comment.
I've seen this handled in a few ways, rvm / pyenv / nvm come to mind.
crane plugin ls and crane plugin ls-remote or something similar with distinct commands for each op?
+1, would be nice to be able to support pointing at github repos and/or local source as well. |
I was thinking that binaries that are download for a particular OS. An image is an option, but then we have to shell to an container runtime, and have to either create manifest-list images for the particular arch/os of the host system or the image is a data dir that contains them all and we have to pull out the right one. Building the images on the machine would then require the setup for the particular plugin. Today, you could write a plugin in bash or in programming language. If we build them dynmaically I would worry that could cause some issues. I also think that this may cause us some issues downstream but maybe I am incorrect on that? I don't know the answer here, because building an image downstream from binaries is going to be problematic as well. I wonder if we actually have to solve this problem before moving this forward? |
It feels to me answering how we intend to distribute these is a question that's within scope here. Downloading binaries makes the most sense to me but it suggests you need to host them somewhere...unsure where that might be. |
|
Superseded by #47 |
No description provided.