We will not be meeting tomorrow, please take this time and record your KubeCon + Cloud Native Con virtual talks! (Suggested use of time.) - amye -- Amye Scavarda Perrin | Program Manager | amye@...

FYI this is great work and should get greater input ---------- Forwarded message --------- From: Emily Fox <themoxiefoxatwork@...> Date: Mon, Oct 19, 2020 at 3:59 PM Subject: [cncf-sig-security] Cloud

+1 NB

+1NB - Emily Fox @TheMoxieFox (personal handle)

+1 non-binding On Oct 16, 2020, 6:44 PM -0400, Chris Short via lists.cncf.io <chris=chrisshort.net@...>, wrote:

+1 non-binding -- Chris Short He/Him/His Advisory | Web | Newsletter | Twitch | Twitter | LinkedIn

Forwarding this along to the TOC and SIG Contributor Strategy, as it has project implications for downstream consumers of Kubernetes. Please join the discussion at

I had 2 suggestions wrt mucking with index.yaml: Use index.yaml to point all chart downloads to a specially crafted chart that causes a hard failure on the users end but provides an error message

Brian/Vic - are you saying continue serving index.yaml from GCS, but modify it to point to .tgz files hosted elsewhere? such as: ? This might cut down on transfer costs, but I think the index is

+Vic Iglesias 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

To be clear, what I was suggesting was not intended to “mess with anyone’s plans” - I was simply trying to lay out that if Helm finds itself in a difficult position here, we (TOC) are here to

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

That's not correct. Who told you that? As I pointed out on https://github.com/helm/community/issues/114: https://cloud.google.com/resource-manager/docs/project-migration Transferring the GCP Project

From what I have been told, it's not technically possible to transfer the project. To add some context about cost and history... We have seen numbers on what it would cost to host these through Google

All we need from Google is for them to redirect the chart repository domain name to a new location. That is the only thing that is currently causing the high-probability risk of the chart repositories

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

Josh, You ask a good question. There are two things worth noting... Many of the charts people use have been slower to move out of the stable and incubator repos than expected. We are still finding

All, I'm really unclear on why CNCF would devote resources to maintaining a set of outdated Helm charts if the Helm project itself has decided not to do so. Wouldn't it be more sensible for us to

+MattButcher --brendan From: cncf-toc@... <cncf-toc@...> on behalf of Brian Grant via lists.cncf.io <briangrant=google.com@...> Sent: Wednesday, October 14, 2020 7:05:41 AM To: Liz Rice

This has been an issue since at least April 2019. The deprecation message is not getting through.