New home for this repo

[billimek]

Now that the helm/charts repo is deprecated and this repo has grown beyond just personal charts, it makes sense to leverage a much better named place to host charts related to k8s at home. @onedr0p, @carpenike, and myself have a k8s-at-home github org that seems like a logical fit for a new home for these charts.

Therefore, we would like to 'transfer' this repo to k8s-at-home and rename it to 'charts'. Github will automatically 'follow' the transfer and rename from the existing repo, so links should continue to work. Transfer approach would not work as expected. Will replicate to the new home instead.

At a high-level, the following will likely be necessary:

• create new repo in https://github.com/k8s-at-home/charts
• clone this repo to preserve git history and push directly as the new charts repo (https://github.com/k8s-at-home/charts)
• freeze contributions from non-maintainers (in both repos)
• Update github actions to reflect new home
• Update gh-pages branch to reflect new home
• Update main and chart READMEs to reflect new home
• Ensure that https://k8s-at-home.com/charts/ points to the transferred repo
• 'transfer' all open issues to new repo
• Add the maintainers for group effort at updating all the different aspects on both repos
• For each chart, create a PR in the old repo to depreacate and reference new home. See [adguard-home] - deprecate adguard-home #346 for an example
• Once new repo is satisfactorily ready/updated merge above branch in old repo
• Archive with established date on main readme saying it will be removed at x date
• unfreeze contributions from non-maintainers (in new repo)

[bjw-s]

Maybe this is also a good moment to think about adding support for CODEOWNERS?

That way you could (for example) automatically assign additional pull request reviews to people you deem responsible for the contents of certain charts.

Also, I wouldn't mind picking up / contributing to some of these tasks, but I guess most of the tasks can't be started on until the first one is done.

[billimek]

@Juggels this is an excellent idea, thank you!

[bjw-s]

As for the CODEOWNERS feature, it seems that currently it's not possible to keep a CODEOWNERS file per chart 😞 That would mean having a single CODEOWNERS file in the repo root folder. It could work, but if the repo grows in terms of charts/PR's the chance of merge conflicts will definitely increase.

[carpenike]

Perhaps management of that file should only be handled by overall program administrators and PRs shouldn't be allowed to it?

[billimek]

Concern that while github will properly redirect a transferred & renamed repo (i.e. the old URLs continue to 'work'), the custom helm repo URL (https://billimek.com/billimek-charts/) will break. Need to test this and see if there is a clean workaround.

Alternatively, an approach could be to stand up a completely separate & new repo over in k8s-at-home/charts and 'deprecate' these charts and update READMEs to direct folks over to the new location. This is less ideal IMO because it will fracture the use and make it not obvious that charts have moved (maybe?).

[dirtycajunrice]

@billimek Just to be clear, why will the above break? Instead of pointing it to a gh-pages directly just point it to a reverse-proxy somewhere and point it at the new location with a rewrite. Thoughts?

[dirtycajunrice]

Actually... now that i think about it more... the deprecation may be the only way to be "graceful" about it. If the url is pointed to the new repo

• users will effectively never have to stop using the url
• there will be no way to separate "new" versions of charts to not show up on the old url
• there would be no way to notify the user that there has even been a migration outside of hoping they check in (vs the deprecation method that lets them know on install/upgrade)

IMO:

• clone the repo to preserve git history and push directly as the new charts repo
• freeze contributions from non-maintainers (in both repos)
• Add the maintainers for group effort at updating all the different aspects on both repos
• create a branch in the old repo to stage full sweep deprecation in one MR
• Once new repo is satisfactorily ready/updated merge above branch in old repo
• Archive with established date on main readme saying it will be removed at x date
• unfreeze contributions from non-maintainers (in new repo)

or something of that nature?

[carpenike]

Another option — why don’t we just keep the dns name as is and work out a migration plan to a new namespace after the migration is complete? We can do a reverse proxy for the k8s-at-home.com namespace and get that working, update all guides to point to new name, then after X period of time we change the DNS name on the repo itself?

[billimek]

@carpenike good idea! The current helm repo address is https://billimek.com/billimek-charts/ which is being handled by github (the billimek.com DNS A record is pointing to github's servers (via the apex domain configuration) so in order to do this, the domain 'A' record will need to first be decoupled from github in order to set-up an external hosting solution to continue serving this helm repo as well as a proper redirect to the new helm repo.

At least, that's how I understand it would need to work.

[carpenike]

You're referring to the future phase / step? We can prove out that remote hosting feature will work with the k8s domain prior to notifying anyone of the change.

[billimek]

@dirtycajunrice I think the steps you suggested are probably the best approach we can take. With the way the currently helm repo URL (https://billimek.com/billimek-charts/) is configured, having it transparently work with a new home simply isn't doable.

Preserving commits is a nice touch instead of a net-new empty repo.

• create new repo in https://github.com/k8s-at-home/charts
• clone this repo to preserve git history and push directly as the new charts repo (https://github.com/k8s-at-home/charts)
• freeze contributions from non-maintainers (in both repos)
• 'transfer' all open issues to new repo
• Add the maintainers for group effort at updating all the different aspects on both repos
• create a branch in the old repo to stage full sweep deprecation in one MR
• Once new repo is satisfactorily ready/updated merge above branch in old repo
• Archive with established date on main readme saying it will be removed at x date
• unfreeze contributions from non-maintainers (in new repo)

What do you all think?

[onedr0p]

@billimek I think this is a great path forward.

Would it be a good idea to have a stable directory and a incubator directory in the change-over.
This would allow us to test out charts before we move them to stable. For example rewrites of charts to statefulsets or other reasons...

[billimek]

Sadly, we cannot transfer issues between organizations:

You can only transfer issues between repositories owned by the same user or organization account.