Open mlavi opened 4 weeks ago
github-actions[bot]
commented
4 weeks ago Thanks for opening this issue :+1:. The team will review it shortly.
If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.
If you haven't already, please take a moment to review our project's Code of Conduct document.
hairyhum
commented
4 weeks ago A bit of context:
This means that the question of "how far back in time do we want chart support" is independent from "where to host chart artifacts" and "where to host charts index".
hairyhum
commented
4 weeks ago NOTE: we need to change old artifacts urls in index.yaml before we switch charts.kanister.io to a new location. @mlavi is there an S3 url we can use to access the bucket?
mlavi
commented
4 weeks ago I've requested charts-new.kanister.io in DNS. Let's test with this "naked" S3 URL http://s3-website-charts.kanister.io.s3-website-us-west-2.amazonaws.com/
hairyhum
commented
3 weeks ago Let's test with this "naked" S3 URL http://s3-website-charts.kanister.io.s3-website-us-west-2.amazonaws.com/
This one gets me 404 error
Currently, http(s)://charts.kasten.io is hosted in AWS S3 under the Veeam account and our current build pipeline publishes artifacts and updates the Chart /index.yaml
For project independence, we should migrate this dependency. We might converge this to main project repo (with the codebase, will also host documentation) or we may move this to it's own repository and GitHub pages. There are arguments for either.
Since this is part of the release process, it begs the question for release artifact management: where to host them and how far back should we keep them?
I propose that we do not need artifacts past the supported Veeam Kasten release (which roughly follows Kubernetes support of 18 months, IIRC), but we should ask for community input!