Re: [URGENT] Impending deletion of Helm 2 releases and charts buckets


Josh Dolitsky
 

Brian/Vic - are you saying continue serving index.yaml from GCS, but modify it to point to .tgz files hosted elsewhere?

such as:

entries:
  alpine:
    - created: 2016-10-06T16:23:20.499814565-06:00
      description: Deploy a basic Alpine Linux pod
      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd
      name: alpine
      urls:
      - https://otherdomain.com/charts/alpine-0.2.0.tgz
      version: 0.2.0

?

This might cut down on transfer costs, but I think the index is actually larger in size than the .tgz's.

Is that what you mean by "redirect via index files"?

- Josh

On Wed, Oct 14, 2020 at 3:48 PM Brian Grant via lists.cncf.io <briangrant=google.com@...> wrote:

On Wed, Oct 14, 2020 at 12:27 PM Matt Farina <matt@...> wrote:

From what I have been told, it's not technically possible to transfer the project.

That's not correct. Who told you that? As I pointed out on https://github.com/helm/community/issues/114:

Transferring the GCP Project to a CNCF GCP Organization and Account would make it easier for you to manage, and has to be done if it's going to continue to exist.

Sorry for the confusion. I've asked multiple people at Google about this and I was told it wasn't possible. Thank you for not only clearing up the confusion but pointing out the project-migration docs.

This still doesn't deal with the funding issue. We've not gone to the GB on funding (it would be well over the limit to just do so GB is needed) because the amount would be high enough that it impacts other CNCF activities like security audits and contractors working on things. We don't want to see that happen.

Now, if Helm could use some of the unused GCP credits for k8s the funding wouldn't be a problem. There are more than enough unused credits. Is transferring the bucket to the CNCF k8s account and setting it up to use some of those credits possible? We would shrink down what the buckets served and it would enable the k8s SIG Service catalog Helm repo to stay alive as it's managed through the same project.

You, Michelle Noorali, and Adam Reese have "Storage Admin" access. There's also a chart uploader service account.

This highlights part of the problem. If we look at the current Helm governance this isn't a list of the right people. Sadly, my access didn't even let me see who the other people were or that my access was "Storage Admin". IAM is a finicky thing.

The lack of ownership is more than a storage problem. For example, not having access to setup a custom domain with HTTPS. You need more than storage admin for that. This is what I meant by a pain point. Or, being able to manage who has access. Of the charts maintainers, I'm the only one on that list. Adam and Michelle aren't. What if I'm unavailable and someone else needs to step in? The reality is that "storage admin" isn't enough to really manage something well. That's what I meant.

Right. There are Googlers who can grant additional permissions, but moving the Project would fix this completely.

Vic had another suggestion: is it possible to redirect via Helm index files?
 

- Matt Farina

On Wed, Oct 14, 2020, at 2:53 PM, Brian Grant wrote:
On Wed, Oct 14, 2020 at 11:50 AM Matt Farina <matt@...> wrote:

From what I have been told, it's not technically possible to transfer the project.

That's not correct. Who told you that? As I pointed out on https://github.com/helm/community/issues/114:

Transferring the GCP Project to a CNCF GCP Organization and Account would make it easier for you to manage, and has to be done if it's going to continue to exist.


You, Michelle Noorali, and Adam Reese have "Storage Admin" access. There's also a chart uploader service account.

 


To add some context about cost and history...

We have seen numbers on what it would cost to host these through Google Cloud. The numbers, if I understood what I saw right, is the public cost rather than the internal cross charge cost. It's a larger number than I ever expected and a cost I'm very hesitant to ask the CNCF to cover as an unexpected expense. Especially during these times.

If there were a bunch of unused Google Cloud Credits laying around I would be happy to use them. But, that doesn't appear to be the case.

Just know, the cost to the CNCF would be substantial.

One of the problems is the hard coded URLs in the Helm client. This was all setup in early 2016 when Jack Greenfield and Ville Aikas were major Helm contributors on behalf of Google. The bucket setup (as with all the Helm Google Cloud services) were setup through Google corp accounts. Googlers controlled them and do to this day.

The lack of ownership by the project has been a pain point. But, older Helm v2 clients are stuck with it (can't do a redirect) and many of them are still in use. The version use across Helm versions is rather large.

What we want is to deprecate the charts repository (headed toward a distributed route) while still keeping things available for people. That includes old versions of charts.

I hope that context helps.

- Matt Farina

On Wed, Oct 14, 2020, at 2:10 PM, Josh Berkus wrote:
On 10/14/20 10:52 AM, Matt Farina wrote:

> There are two things worth noting...

>  1. Many of the charts people use have been slower to move out of the
>     stable and incubator repos than expected. We are still finding them
>     new homes. So, not everything is deprecated. There are many useful
>     things there.
>  2. There is more use of the stable and incubator repos than I ever
>     expected. I'm told the use is growing even as things move off it.
>     When I recently saw some numbers I was amazingly surprised. I had
>     expected it to be lower. Note, I don't have access to this data. The
>     buckets are Google owned/managed so only they have access to this. I
>     think Vic is the only one of the Helm maintainers with access to this.

> Many people will have some pain when the stable and incubator repos go away.

My question is: is the *Helm project* asking for the CNCF to fund
extended storage for these charts, or not? (assuming this is technically
possible).  I can see why the answer might be "not"; we have break the
links to the old locations sometime, and why not now?

The request to the TOC came from a concerned contributor, not from the
project leadership, as far as I can tell.

For my part, I would not want to see the TOC messing with a project's
official deprecation plans without a formal project request.

-- 
--
Josh Berkus
Kubernetes Community
Red Hat OSPO






Join cncf-toc@lists.cncf.io to automatically receive all group messages.