 but how have you guys been doing? Good, good, good. We're moving on. I don't know if you saw the Helm Hub is officially migrating to the artifact hub. So that's the interesting thing for this project. So congrats, Matt, I think that's spectacular. But otherwise things are generally good except I've got construction on my home for the last couple of weeks. I'm looking forward to that being done. And we got enough rain here that I think the lake behind my house went up an inch. Is there an open issue on the Helm Hub becoming artifact hub? Yes, there is. And I'll pull that issue up here. We have a list of tasks we're doing as part of this and walking through the migration. It is at, we dropped it into chat here. And so we should probably kick this off and that's the first item to talk about on the agenda. Great. All right, so here's the agenda. So this is the Tuesday, September 8th, 2020 artifact hub call. I dropped the agenda in. And the first one is the Helm Hub to artifact hub status. And the status of it is the artifact hub now has all of the repositories that people have not already added themselves, moved over. They are managed by the Helm Organization and Artifact Hub. And a process has been put in place to allow transfers by claiming a repository. And so somebody can come along and actually claim one as their own to take it back from us managing at the Helm work. On the Helm side, we have already gone through all of our governance channels to approve this. And so now it's just a matter of executing on it. Today, I was going to write up the documentation on the Helm Hub and start sharing it so people know about it. It's actually gone up to the mailing list already. And so that's where I'm at, is step two, clearly document how Helm Hub Repowners can transfer unless the repository is an artifact hub. That's what I'm going to be working on today. And then we know we've got to work out the domain redirect. And I don't know whether at first we'll just do it through an app or whether we'll jump in and have it be set up through DNS. Yeah, that's something we still got to figure out. If it's a DNS, which it'll eventually become, but in the first get go will be DNS, we'll be filing a ticket with a CNCF to have that set up. Yeah, I just think this is all fantastic. And Scott has a PR against Helm itself to fix a couple of things because hub.helm.sh is hard coded in some places or as the default. And this will actually clean up the response to allow redirects in future Helm. And so that's there as well. So that's where we're at. Several of these repositories have issues in them. And so I've been getting spammed with notification emails about the issues in these repositories. I think over the course of the weekend and maybe last Thursday and Friday, I think I ended up with like 175 of them notifications. So I'm starting to go through and let people know they can claim them so they can get notified or clean up their issues and the repositories that have issues. That's where I see Scott and Paul have joined. I was just kind of giving an update on where we stand in the migration. We don't have a set date on it yet, but we're moving along with it. Did you all have anything you wanted to add? Just that the Zoom link in the CNCF calendar is wrong. Thank you. I will let Amy know to update that. Thank you. That's why we were a little bit late. Okay. Yeah, we were just chatting over in the other room. But good to see you all. Good to see you too. I hope you had a quality conversation. Always. Was there anything? I can see your avatar, Dan. Yeah, nice to see you. Matt, yes. But I did have one thing to bring up. I didn't put it on the agenda though, if that's okay. The issue about readme links. Yes. Comments. Both of your comments there too and you, Matt. I only have one question. By the way, I agree. I think it is a shame for readme is to have to have full URLs, but given that we support sources from all different places and they have special rendering, it's just not feasible. Also the option to package random files is also, like you said, it could open us up by being a weird, weird possible tax. There's this other strange thing. Even extra large packages, if need, unnecessarily too. The only thing I wanted to ask was about the source. The source key you mentioned. I know we have a sources, but that's not really used for the source code to the chart itself. For most current charts, it's used for, it's an array for like various sources like for instance, even the upstream project or the container image source or whatever. Yes, it is not specific just for the source code itself, but that's where you can put the source code for maybe the application, the chart. You can put any of those things in that array. It would be nice if it was a key value pair rather than just a list of URLs because that would make it easier to display, but it's not, we can't change that. Now, but we could add something potentially. So anyway, I think that sounds like the scope of this because it's more of a home conversation, but it might be worth following up. Yeah, I agree. And it might even be something where like in a future version of the Helm spec, the like the chart spec, we even have the option to put like your images and icons and stuff in the chart itself. And that way anything that wants to render stuff like images can actually, if they want, open that chart up and grab them out. But we have to figure out how that would look. So my lazy man's route to that would probably, are you familiar with data URLs? You can take something like an image, convert it into a data URL and embed it because the image is actually embedded in the URL. That would be a possible way to do these things. I have not experimented much with it to see what changes would be required or how big files would get. But that would be my short-term easy method because it would require, I think the fewest number of changes. It's a URL format. So these are URLs. Or even just the normal markdown image path as long as it's a full, full, fully qualified, excuse me, a full URL. You know what I mean? Anything would work as long as we're not expecting to reproduce all the special magic rendering that different projects out there have like GitHub, et cetera. If I understand correctly, we probably don't want to build that into artifact stuff, right? I wouldn't suggest right now. If we did, we'd have to take care for security and all that good stuff. Yeah, keep it simple, cool. I'm just gonna, just to surround that one out, I'll send a note to the Helm eBase chat where we're talking about the next blog post and just put that on our list maybe to try to include if we can. Okay. Okay. The next item in the agenda is actually something that came up earlier today. I was talking with Remus over at JFrog. And so the Helm incubator and stable repositories are going to go away. We're figuring out if there's a way we can have an archive in case somebody does need to get to something and things of that nature. But JFrog Chart Center has a copy of all of the charts. An incubator and stable, that's like about 900 megs. These charts are just small, right? It's totaled about 900 megs. But they have a copy of all of them that you can get through Chart Center. And so they are going to have that going forward even after the stable and incubator repositories are gone. So that is one option we can start to tell people about. But they've actually asked Artifact Hub and there was an issue filed this morning on it. If there was a way to get a list of the chart repos in programmatic form because Chart Center would really like to know about any new repositories in order to add it to itself. And this is something we wouldn't just do for Chart Center because we wouldn't wanna prioritize anyone vendor, but it's something that could be a public API somebody could periodically hit to find out the repositories. Kind of reminded me of that catalog API on the distribution stack. What do you all think about that? Matt, I don't know if you've seen my reply on that issue. No, I haven't. Okay, but we already have an API endpoint for that. Oh, all right. Yeah, so I have, yeah, I've commented on that one. Wow, look at that, you're ahead of the game. Okay, well, that's all I had. Does anybody else have anything else that? Matt, I think you need to mute for a second. I had kind of an open-ended question or a possible feature direction, but I would emphasize it's low priority and open-ended. So first is a question about Operator Hub where it looks like they have 152 items in it. And yet, oh, and I guess we have 153. So I'm gonna call that close enough not to worry about it when I turn off a category. But the open-ended question is around would it possibly make sense to try and talk about operators without being specific as to OLM or CUDO or non-OLM, non-CUDO operators? And so essentially, is it conceivable that you could have some metadata around a Helm chart or around an artifact more generally to be able to say this is an operator? And it may just be that it's too metaphysical question. I was sort of envisioning that something that included a CRD would count as a operator, but maybe you wanna push back and say, no, that's not necessarily the case. But anyway, that was my thought for you is would it make sense? Because jumping ahead, one of the things that I loved about Operator Hub is that five different levels of becoming an operator where the fifth one is like the super autopilot and then there's ones in between. But I'm particularly interested in our ability to automate that as opposed to just letting people click a box and say, oh, I'm a fifth level one. Yeah, so this actually gets really hard. So in the TOC, in the SIGAP delivery, they created an operator working group and the operator working group dove into this. One of their ideas was to try to come up with a general piece of metadata everybody could use. We weren't able to come to that. And then they talked about that whole, that five level things you got into. And they discussed it. Here it is. Since we can't check. Yeah, and so they discussed it and they talked it. A lot of this was always created in the marketing effort to talk about levels and things like that. And so they got into, and I'd have to dig it up their own version of levels that was different from this in some ways. And they could never quite get consensus or work it out. Exactly what it meant and how you rate things. And there was just some difficulty around it. So I like having something that gives you more information, but this was very much targeted at the OLM based operator goals. And not all operators are that way. And so if we have a general thing, it probably needs to be evaluated. I don't know if we'd have the same things. I actually don't know, because they weren't able to publish something. Is this the kind of thing we should go try to figure out as a project since the working group hasn't? I mean, it would certainly be better if the working group came up with the answer and we could just leverage what they had. It would. The working group is basically stalled and has been unable to produce. So this is something where somebody would have to go sit there and try to drive it to get them going again. Matt, I wonder if we could offer kind of the helm packaging and sharing mechanisms for operators. Because I mean, we already have a lot of that stuff and it wouldn't be too hard to add. And then if we have a like operator.yaml as opposed to the chart.yaml that contains most of the metadata, we could in theory have a like a maturity setting where they would pick from the five levels or whatever. It could be displayed. Yeah, so this gets into which projects would adopt it? Like how do you get OLM to adopt it? How do you get Kudo to adopt it? How do you have it as a generic thing that could be stuck in if somebody's had a collection of say Kubernetes YAML files to adopt it, right? How would you get different groups to work together to adopt the same format? And that's one of the problems. The OLM folks have also talked about they're moving to a new way to distribute things. It's a container-based thing. I'm not exactly sure how it works. They explained it to me in the last one of their meetings that I went to, but we didn't get into technical detail because they said it was so new, it was alpha or beta and I, like it was so new that I had never heard of it and they had to point me to it. And so they're looking to change things up there. I like the idea of having something. I'm just not sure how to get the different players on the same page with it. Yeah, I had been under the assumption that we wouldn't require any changes from anybody and that we could just introspect their work. Yeah, with the levels though, how would we introspect their work to know the levels? Yeah, how about if we skip the level for a second and just ask operator Boolean true or false? We could probably come up with a way to do that. What would it look like for Helm charts? I was gonna say that if you look at the bottom of the filters on the left side, we have already an operator filter. At the moment, the mechanism is very simple. So all OLM operators are being flagged. We have that flag enabled for them and for Helm charts, the ones that have the operator word in the name are being flagged as operators as well. So it's just to do it a bit of, I mean, automatically without user have to, I mean, populate any metadata that actually doesn't exist on the chart JML. So it's simple, but it's adding some more operators to the equation. And now a user recently suggested this that why, because we already have a custom metadata format for ArtifactApp. So the user was asking, why don't we allow to overwrite some of the values that we can't write at the moment in a chart JML file with some custom values from the metadata, from the ArtifactApp metadata file. And that could be another option. So the users, we just need to create that file and set the operator flag to true and we could overwrite them. And even in the short term, we could do something like an annotation in the chart.yaml file. This is something like operator truth. We could start publicizing that as a pseudo thing. Kubernetes is known to use annotations, right? To do this kind of thing. We could do the same thing. What about using the chart types? Like we already have application and library. That's gonna have implications. That'll have implications on Helm's ability to install things though. So we couldn't just do that without making a change to Helm. Well, what I was thinking of is the main use of it would be if the person is going to use it to template out the CRDs and then use it as the dependency for their other charts. Which is kind of one of the patterns we've talked about being sort of an acceptable way for people to install operators using Helm anyway. So it might be an interesting way to explore that a little bit deeper. And worst case, it could be just the CRDs directory, the chart.yaml and it's kind of a packaged up operator. We lost Matt, unfortunately. I would explain why he was being so quiet. Scott, what do you think of that? Good idea. I think, you know, I personally tend to lean for it. Keeping bearing in mind that, you know, we all know that the specs for Helm charts are in a more stable place than they have been before, you know, even more so. And we want to, you know, ensure that we maintain backwards compatibility and we don't, you know, mess around with things for users. I think that does seem like pretty good work around. I do, like I lean toward wanting to add additional metadata, you know what I mean, for like a minor version so that we can, you know, in an upcoming minor version and think really think through it so that we, once we add it, we can't take it away. At least until the next major, you know, so if there is some good, you know, really good value for being a bit more structured, let's say in chart.yaml or whatever, that would be nice and well. Yeah, adding to that, I'd really like to adopt the Kubernetes style, like API format, which we're kind of there anyway, where you just need to add the extra fields. And that could be, I don't know if we could get away with it on the Helm 2 spec, but we could certainly get working on a Helm 3 spec if there's something breaking in there. Like metadata name might be an issue, but that also might be something where we say, well, we already accept you having a name. If you have metadata name, then maybe we'll override it or something. We can figure that out. Yeah, that's what we've been doing with Slack anyway. Yeah, so. Because then we have access to, you know, like since we have the metadata, then we can do labels, annotations, we can do a bunch of stuff. Yeah, that'd be really cool. Yeah, I think pertaining to Artifact Hub, I think, you know, it can be a little bit more, you know, right now, if I understand correctly, Sergio is looking at that issue and, you know, I followed it and I may comment on that at some point, but I think based on that and some of the other related issues that we've been talking about and you've already, you all have already worked on, you know, I think you have already worked on, I think the pollution is to provide additional metadata, metadata files, optional metadata files that are Artifact Hub specific and use those for things like override or whatever else. That seems like a good strategy, you know, at least for now. And the nice thing is Artifact Hub is, you know, still pre-release. So you can add those things and then as they become available, those same benefits become available, safer home packages. You could end up either sunset those or not worry about them anymore. Yeah, exactly. So we're planning to work on that ticket soon and so that feature will be available and we can stop flagging the operators and health charts just by the name, instead of by the name by using that metadata. And we can even go a bit further and start using like the capability level that Dan was mentioning before. So it's our own metadata file. We can allow there whatever we want. And it's already available to users and whenever they're up to it and they, they add it, we can leverage it and display it in Artifact Hub. Also, can I just, I'm gonna have to get off in just a few moments to possibly defer back in a second. I'm not sure because I have to do a meeting. I'm back, I'm back. So cool, hey. Well, I'll still say this anyway, because it's still relevant. I just wanted to quickly say that to all of you, I'm really impressed by how quickly the Artifact Hub project has come together and the value that it provides is so obvious, I think. And it's basically just a clap to you all on a couple of minutes. And I would like, if I can, to contribute a little bit more, I'm not sure how much, but I think it's a really great initiative. Thank you, Scott. Yeah, thanks so much for saying that, Scott. I'm also very excited about the progress. So maybe a takeaway for the Helm folks is we have a think about how we might add some fields to chart.yaml or start working on a V3 or something. I would start with the annotations before we make anything. So that way it's backwards compatible where people are already using versions of Helm. There's enough people who don't upgrade quick enough and we'd want something that they can use. So I would start with that as our first stepping stone, because that's so lo-fi. Yeah, so basically add a metadata.annotations field and allow people to fill that out and just kind of follow the pattern that Kubernetes already has for doing annotations. And Helm has annotations in the chartyaml file right now. It does. It totally does. That's why I'm saying we could literally just have an annotation in the chartyaml file that's just something like operate or true and that will work with all charts, even in Helm V2. Absolutely. Ah, that's really cool. Actually, the other thing that might help solve the issue Scott was talking about earlier with relative links is we could have an annotation for URL prefix. Oh, I hadn't thought of that. I really liked the idea that didn't even, yeah, that didn't cross my mind either, but that kind of satisfies the key values there comment that you made earlier, Matt. Yeah. All right, so we will, since there's only two minutes left, we will take that away as Helm folks and propose some kind of ideas using this and see what we can come up with. Okay? Awesome. Two last comments, we do want to try to get the Kudo ones in here at some point and have them listed as operator as well. Yes, I've actually reached out to the Kudo folks on it and it's now a matter of we got to sit down and figure this out, but they totally want to and I've already reached out to them. And then my last thought is that as the switchover from Helm Hub to Artifact Hub occurs, seems like a good time to switch from alpha to a beta label. Oh, that's tricky. I like it. That sounds good. Sounds good to me. There's just a couple of weeks. Yeah, there's also somebody in the community who may be taking Artifact Hub and bundling it with their distribution to search the repositories of stuff they've got in their distribution. And so that would be probably useful for them to know too. Great. Okay, thanks everyone for the call. Thanks everyone for coming. This was great. Thank you. Have a wonderful day. Thank you.