Closed tegioz closed 3 years ago
chriskim06
commented
3 years ago Hey @tegioz, thanks for filing this issue! I haven't had time yet to look into this but I'll try to look through the Artifact Hub docs you've linked soon to get a better understanding.
chriskim06
commented
3 years ago @tegioz sorry for taking so long to get to this! This seems relatively straightforward but I have a couple concerns. If we wanted to use the Kubernetes organization (and I'm not sure we would, this is a kubernetes-sigs project) then I'd need to be added to that org right? If we were to use kubernetes-sigs as a new org I think we'd need to get some kind of authorization maybe from the larger community to use that name (also I was playing around in artifacthub and tried creating an org with that name but it said kubernetes-sigs was already taken but I don't see it in the list of publishers when I search).
@ahmetb @corneliusweig what are your guys' thoughts on this?
ahmetb
commented
3 years ago So we already have plugin discovery at our website, but I'm not against Artifact Hub listing kubectl plugins from Krew on its site either.
I might however be against us maintainers getting involved in maintaining our presence on Artifact Hub (as it's one more responsibility, and we already have a decent amount of it). It clearly seems that the data flows there without the need for maintainers’ involvement.
We've also added support for some AH specific annotations
I don't think we’d go into incorporating these annotations in our docs, as we're trying to keep things simple for plugin authors.
If the plugin authors want to add them, we won’t prevent it; but the history has proven several times that trying to get >130 plugin manifests updated is quite cumbersome (as most of the manifests are autogenerated from plugin repos via our release bots).
Overall I’m not entirely sure if Artifact Hub is in the well-lit path of discovering plugins and alike tools already. If it requires minimal involvement from us, it can be ok to polish our presence, but probably not invest further.
tegioz
commented
3 years ago Hi @chriskim06,
No worries at all, I appreciate you getting involved on this 🙂
If we wanted to use the Kubernetes organization (and I'm not sure we would, this is a kubernetes-sigs project) then I'd need to be added to that org right?
Yes, if it already exists, you'd need to be added to it or ask anyone on it to claim the ownership (you could list them as owners in the artifacthub-repo.yaml file). In addition to claiming a repository's ownership, you can also transfer it to another organization you belong to or your own user account at any time. So if you change your mind later on it shouldn't be a problem making changes.
(also I was playing around in artifacthub and tried creating an org with that name but it said kubernetes-sigs was already taken but I don't see it in the list of publishers when I search).
Maybe someone has already created it to reserve it but no content has been published yet under that organization.
Thanks @ahmetb. We've starting added support for plugins (kubectl and helm) recently, but if you think there is something we could do to improve how they are presented or discovered please let us know, feedback is very welcome 🙂
corneliusweig
commented
3 years ago Hey @tegioz, thanks for setting this up, this looks great!
As far as I'm concerned, I see the artifacthub.io plugin mirror as a community contribution. It's nice to have it, but not essential for krew. Also, I don't see trust issues if the AH entries are not associated with kubernetes-sigs or a krew org, because all they do is giving CLI snippets to feed to krew. So I'm very comfortable with the current state.
Thanks again for setting this up!
Regarding annotations in the manifests: I think it's very unlikely that we will ever add those, because they would for the most part just duplicate information that is already in there. But what do you think about adapting your import job, so that it adds those fields and fills them using the fields from krew manifests?
tegioz
commented
3 years ago Hi @corneliusweig,
Cool, thanks 🙂
When the repository is not the default krew index, the installation instructions also show the user how to add the repository first. This would be an example currently available on artifacthub.io:
Regarding the annotations we support for krew, the intention was to give users the chance to include some extra information I couldn't find in the krew manifests. The manifests are already the main source of information when processing krew index repositories, and if there is something in the annotations already covered in the manifests that I forgot to include, or even if that happens in the future with new additions to the manifest, I'd be happy to update it. The easier it's for users, the better, so we'd rather avoiding unneeded duplicities.
Users owning plugins available in the default krew index may see them in Artifact Hub and realize there is some extra context they'd like to provide, as a license, or some extra links. The same can happen for other krew indexes available, like the one shown in the screenshot above. Annotations should allow them to make the most of some AH specific features that aren't necessarily useful for the core functionality of krew.
Thanks again!
corneliusweig
commented
3 years ago @tegioz ah.. you are right, you are already taking all the fields from manifests. Although you could fit example also show chips with the supported platforms in your UI (out did I again overlook something?)
Anyway, although we are unlikely to add these annotations to existing manifests, we could think of including the possibility of enhancing the AH appearance with metadata tags in our documentation. WDYT @chriskim06 @ahmetb?
tegioz
commented
3 years ago Yes, displaying the supported platforms would be a nice addition. We'll gladly add support for any extra piece of information available in your manifests that fits well in Artifact Hub 🙂
ahmetb
commented
3 years ago Anyway, although we are unlikely to add these annotations to existing manifests, we could think of including the possibility of enhancing the AH appearance with metadata tags in our documentation. WDYT @chriskim06 @ahmetb?
I've explained this above, I think it probably shouldn't be yet another thing plugin authors need to worry about. If they discover Artifact Hub, they can refer to their docs on how to improve their page by adding annotations in our repo. (We can also link to docs on Artifact Hub, but not too extensively.)
It's critical for us to make it as easy as possible to distribute plugins on Krew, so I wouldn't want this to be another thing developers need to worry about. Right now, they don't do anything special to show up on https://krew.sigs.k8s.io/plugins/.
Yes, displaying the supported platforms would be a nice addition. We'll gladly add support for any extra piece of information available in your manifests that fits well in Artifact Hub 🙂
@tegioz you can determine which platforms are available from the plugin manifest directly (platforms[*].selector). No new annotations etc should be necessary.
tegioz
commented
3 years ago @tegioz you can determine which platforms are available from the plugin manifest directly (
platforms[*].selector). No new annotations etc should be necessary.
Thanks @ahmetb. When I said it'd be a nice addition I meant to Artifact Hub. I saw the platforms already available in the manifest, but my point was that if at some point you add something extra because it's useful to krew itself, or that you think the plugins view in Artifact Hub can be improved in any way, we'll be happy to work on it 🙂.
The main problem I see right now is that the description of many of the plugins (like this one) doesn't have much content, and the package view seems kind of empty. Others with some content, like this one, look a bit nicer. Yesterday we added support for Tekton tasks, and most of them provide a README file with a lot of content, which helps. Helm plugins, another recent addition, also provide a README file in markdown format.
But as you said, if users discover Artifact Hub they can either add more details to the already existing description field in the manifest or use the readme annotation. So hopefully it'll get better eventually.
Thank you all again! Please don't hesitate pinging us if we can be of any help.
chriskim06
commented
3 years ago Ok so I reached out in the artifact-hub slack channel in the cncf slack to find out who owns the kubernetes-sigs org in artifact hub. Looping in @scottrigby, would you mind adding me to that artifact hub org? My username is the same as it is here, chriskim06.
scottrigby
commented
3 years ago @chriskim06 I added your user to that org on artifact hub 👍 You'll just need to accept the invite. From that point on you can add others as needed (I would just do my best to take the same precautions and transparency like in this issue). In future, as membership grows, we could introduce artifact hub fine grained permissions, but for now it's flat. Thanks!
tegioz
commented
3 years ago Although you could fit example also show chips with the supported platforms in your UI
This is ready @corneliusweig, we'll deploy it later on today.
tegioz
commented
3 years ago The main problem I see right now is that the description of many of the plugins (like this one) doesn't have much content
We are now also displaying the manifest yaml in the package view.
fejta-bot
commented
3 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
fejta-bot
commented
3 years ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
fejta-bot
commented
3 years ago Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-contributor-experience at kubernetes/community. /close
k8s-ci-robot
commented
3 years ago @fejta-bot: Closing this issue.
Hi 👋
We've just added support for Krew index repositories to Artifact Hub. This will allow publishers listing the kubectl plugins available in their repositories in Artifact Hub.
The default Krew index repository has been added as an example. At the moment the publisher is the Artifact Hub organization, but it would be great if you could claim its ownership, so that the legit owner appears as the publisher. It's an easy and fully automated process documented here. There is already a Kubernetes organization registered in Artifact Hub that is publishing some packages, like the nginx ingress controller. Maybe you'd like to use that one if possible, whatever you think suits better.
Artifact Hub scans repositories periodically so any new plugins added or updated in the
krew-indexrepository will be listed automatically. We've also added support for some AH specific annotations that can be used to improve users' experience in the UI.Thank you very much!