 Hi. Hello. Hello, Matt. How are you? Good. Yeah. I'm good. Cool. I'm good. I've been back to back to back meetings. All right, this is started recording. So, I guess we'll get started. Today is this is the artifact hub meeting for Tuesday, October 27, 2020. I added two things to the agenda. Did either of you have anything to add to the agenda? No. Okay. The first one that I had was the blog. The idea that I had. So I've noticed in the artifact hub room in Slack, you've posted a lot of useful and wonderful information. And I thought, you know what, this would probably serve better on a blog that could be tweeted out and shared out and other avenues, which would pull more people into the artifact hub into seeing it and knowing it and using it. What do you think about that? It's a great idea and we should definitely do it. So maybe we could try to define, I mean, so interesting topics that starting from the beginning, like maybe the first one could be just introducing artifact hub a bit more and explaining to users how to add their first repo. And, you know, we can define a few topics and right. So no, I think it's great. So, yeah. So the question would be, what platform of choice would you all like to have for the blog? I have no preference. Many of the CNCF projects use Hugo and static site generation. But I don't care. We're not loggers actually so we don't have any, any preference. So, Okay, okay, whatever you find for us. And I'll be happy to take this action to go start sorting through how we would do this. And I'll try to figure something out. Okay, cool. Awesome. I might ask for some help just to style it like our site or somehow similar I had, but that's about it. I will probably go with the standard setup that the CNCF tends to use to do this. I'll be in line with everything else. All right, sounds great. Okay. It'll, it'll, it'll be a couple of weeks before something is up and running, because I'm scrambling around and help and stuff right now. But this is something I will carve out time for. Okay. Yeah, sounds good. And then the second thing is the helm hub redirect that I had. So right now we get every request comes to the helm project and then just gets forwarded on. There is no nice way to do a DNS redirect to just say hey, use this other thing and redirect here. So we have to have a redirect somewhere. And we could have it on the helm side, or we could have it on the artifact hub side, right, like we could do a C name and then you could catch it and redirect. So there's, there's a few different ways we could do it. And I didn't know whether we had a preference on this project on how we wanted to look at that redirect. If there's an easy way to do it in the CDN here, or the same way that we use at the beginning of the project to redirect when we chose the, the temporary name would be to do it on the AWS ALB. So I would just, I would just set up that on the AWS Ingress, the ALB Ingress we are using at the beginning of the project. So if we do that, I would need you to authorize me to set up a certificate for hub.helm.sh to set it up on AWS certificate manager. So if I do that, then I prepare the redirection on the Ingress side. And once it's ready and everything is working, you can change the a entry for hub.helm.sh and point it to cloud front. Okay. Now, with the hub.helm.sh, we get every single request in for that API that you have being cached for all those funny strings we were talking about being, those all hit hub.helm.sh. How much of an impact would that have over here with the load balancer set up? We are already getting those. So I think you're redirecting everything to us. So that wouldn't change anything. Okay. I still have to take this to the Helm project to figure out what we want to do over there, but I just wanted to see here what we thought. We may just keep the redirect as is, but I'll talk to folks over there. All right. I mean, if we go the way I have proposed, Matt, you still have full control of the redirect because in the end you are the one changing hub.helm.sh to point it to cloud front. So, and you can revoke the certificate thing at any moment. So, yep. We already have seen, I don't know if we have still it in place, the one we set up at the beginning, but it's quite easy and you wouldn't have to maintain the service just for the redirection. We have to have the servers anyway for other things. And so I will talk to folks and in fact it's actually a pretty minimal cost compared to every other thing we have that costs on Helm. It's a drop in the bucket. So, okay. Okay. Those are the only things I had. I hope to take it to the Helm project discussion last week, but we ran out of time in the week before we ran out of time. So we'll see if I can get it in this week. Awesome. I mean, I can do the hour part of the setup quickly from one day to the other. So it won't take much time. Okay. Great. All right. Nice. So there is something that maybe I don't know it's about the official artifact ticket that we still have open. I don't know if maybe we could try to gather some ideas, maybe for the next meeting on what people should do is they want to claim the official status and artifact have at the moment we have a few that have been done manually by me and I'm happy to keep doing that we just to probably define what they should do when they want to claim that status. I mean, if it's only okay I'm the owner of this repo you can go and check it out and please give me this batch temporarily and I promise that in my repo the only thing that is going to be is the software that I own or I don't know we just can we do it, not at the repo level, but at the chart level. So it's only certain charts in a particular repo. I mean, we could do it at the moment is not like it's working it's per repo. But we could try to change that I would need to review the implications because at the moment I went this way for a reason that I can't remember right now. So the reason I think about this is I'm reminded of we've had a couple of times or somebody's had a home repository, and they've had their official ones in there. And then they forked somebody else's and stuck them in there for some reason but it wasn't an official place. And so I knew they didn't keep everything that was their own. In this case, they had a fork version, one case I remember had a fork version of cert manager. The cert manager was updated they got rid of their forked version, but for a while they had to keep a forked version of it to work with everything else they had going on. And I would not be surprised if you had something else like that. On the other hand, if we have fit per package, and so are they supposed to request that for every single package they have from the repo? I mean, at the moment we have the promissues one that has like 15 or 16. And recently, I don't know I can't remember the name, but another one that I approved recently that has five or six. So it's going to maybe become a little bit extra work. We can do it, but then we need to define if they need to request that per package. And if they release another package, they need to again, because they are just another thing to their own software. I say, you need to request again the official status for this extra package. How do you do it? Do you manually have to alter the database or is there a user interface? No, at the moment I do it in the database and given that this per repo is just, I mean, I'm just updating a single field. So it's quite easy. It would be the same for a package is that we need to do it, but it would create more work on their side requesting it individually. Yes. Someone recently mentioned doing it per organization, but that would be even, I mean, one step further because we can always create multiple repositories. It's not the end of the, so you say, okay, this is my official repo and this is another repo I have for some stuff that is not official. That's a good question. I'm going to think about this. I don't know and I would be curious to know if you could remember that reason. But doesn't matter if we think that that's the best way of doing it, we can change it. So it's not a problem at all. So even if it's a little bit extra maintenance work, not. And if it's one of those things that has a user interface on it, it's something that I or if we get other maintainers in here could go spend time doing. So it doesn't have to all fall on you. Okay. Yeah, at the moment there isn't any super user UI. So I think maybe it's early for that because we don't know what kind of maintenance. We will need to do but I'm happy to chair any credentials so that you guys can step up and do it manually in the database as well as if you want to. But it's not a problem for me super quick. So it's an update and I did in a second. It's just nothing. So, yeah. Okay. Okay, yeah, if you can think of that reason I'm going to think about this and I've got a couple of people I want to go talk to, to just bounce the idea off of. Okay. And Dan is somebody I want to talk to about this because he might have ideas. So I might go chase him down now about this one. Okay, cool. If we can also think about something that would allow us to automate this but at the moment I don't I don't have any good idea to say okay we don't need to maintain this. So, Okay, that's a good idea. Okay. Do we have anything else. No, I think that's it. Well then have a wonderful week, and I'll see you online. You too. Thank you. See you soon. Thank you. Thank you very much.