replicatedhq/unfork

Kubectl plugin to find forked Helm Charts and other K8s resources and unfork them with Kustomize

kubectl unfork

A kubectl plugin to find forked helm charts running in a cluster, extract Kustomize compatible patches, and allow you to delete the fork and return to the upstream Chart, while preserving your patches.

Usage:

curl https://unfork.io/install | bash
kubectl unfork

This plugin will:

• Connect to your Kubernetes cluster and search for a Helm Tiller pod.
• Connect to your Tiller using the Helm GRPC API and query to receive a list of all installed Helm Charts.
• Meanwhile, Unfork will download a list of all known Helm Charts from Monocular.
• Comparing your Helm charts with the Monocular index, Unfork will attempt to determine which upstream your fork is from.
• Once you've confirmed the best upstream, Unfork will convert your custom changes into Kustomize patches and resources.
• You can now update the Helm chart to the latest version, and re-apply your patches.

Note: Unfork does not make any changes to the applications running in your cluster. Unfork only needs access to your cluster in order to port-forward and gain access to Tiller.

unfork's Issues

Unfork dirs should reflect the name of the chart, not a random name

Unforking stable/mysql results (for me) in a dir intent-lynx. This feels to be a suboptimal naming scheme.

Unfork panics when used on stable/bookstack (chart with a dependency)

I saw this wonderful tool demonstrated at the Helm Summit last month and I had an opportunity to try using it today, when I noticed that my Bookstack wiki is down and segfaulting.

I don't know why, but I have a forked chart with some of my own changes in it, and I may have lost track of the original directory, so I was going to try upgrading first, and let Unfork help me sort out the changes that I made (that is what it's for).

I have replaced the mariadb dependency in my own version, possibly even removed it, because I am using a managed database provided by KubeDB, which is much better than the bitnami chart that was provided for example use. That could be what causes this error, I am assuming that this error is more narrow than I think it is, (and probably doesn't really affect every chart with a dependency in charts/)

Is there some debugging output that I can provide that will help narrow down the cause of this error and what patch might be needed to accommodate this particular use case?

Here is the error I experienced:

panic: failed to render forked chart: failed to render chart: found in requirements.yaml, but missing in charts/ directory: mariadb

goroutine 1 [running]:
github.com/replicatedhq/unfork/cmd/unfork/cli.(*Home).handleEvent(0xc0000e2790, 0x0, 0xc000a74008, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/replicatedhq/unfork/cmd/unfork/cli/home.go:224 +0xeb8
github.com/replicatedhq/unfork/cmd/unfork/cli.(*UnforkUI).eventLoop(0xc007513cf0, 0x0, 0x0)
	/go/src/github.com/replicatedhq/unfork/cmd/unfork/cli/root.go:162 +0x109
github.com/replicatedhq/unfork/cmd/unfork/cli.RootCmd.func2(0xc00045d400, 0x31f36b8, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/replicatedhq/unfork/cmd/unfork/cli/root.go:114 +0x4b5
github.com/spf13/cobra.(*Command).execute(0xc00045d400, 0xc00009e190, 0x0, 0x0, 0xc00045d400, 0xc00009e190)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:826 +0x465
github.com/spf13/cobra.(*Command).ExecuteC(0xc00045d400, 0x2353460, 0x0, 0x0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:914 +0x2fc
github.com/spf13/cobra.(*Command).Execute(...)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:864
github.com/replicatedhq/unfork/cmd/unfork/cli.InitAndExecute()
	/go/src/github.com/replicatedhq/unfork/cmd/unfork/cli/root.go:138 +0x2c
main.main()
	/go/src/github.com/replicatedhq/unfork/cmd/unfork/main.go:9 +0x20

The steps I took were (first, confirm I can reach the cluster and helm tiller manually, then)

1. kubectl unfork
2. select the "bookstack" release I have installed at Chart Version 1.1.0
3. select the closest version, stable/bookstack (which was detected correctly)
4. press enter, acknowledge, yes

Have you seen this one before?

Is this compatible with helm3?

Hello,

I see a dependency on tiller. Wanted to have a confirmation if this is then targeted only for helm2 and not helm3

Unforking: Handle directory already exists

Today we return an error if the target directory already exists. We should prompt to overwrite it or create a new dir with a -n suffix

Some monocular repos are unavailable when building index, and CLI doesn't handle this very well

$ k unfork

Building a local index of available Helm charts. This is needed to find the best upstream, and will only take a few seconds
getting version info for charts in repo weave-flux (https://weaveworks.github.io/flux/)failed to fetch charts in repo weave-flux, error was &errors.errorString{s:"Failed to fetch https://weaveworks.github.io/flux/index.yaml : 404 Not Found"}
getting version info for charts in repo zammad (https://zammad.github.io)found 878 total repos, and 16339 total versions

This line should be displayed, but it includes a newline, which causes undesirable Terminal UX

unfork dirs should not be created in ~

We shouldn't leave dirs with names like intent-lynx or jaunty-quail lying around in ~ - we should use something like ~/unfork instead

After unfork is completed, show next steps

We should show the next steps after successfully unforking.

This are:

Your unforked Chart is available at ~/path/name

You can install the same version with:
kubectl apply -k ~/path/name/overlays/downstreams/unforked

You can update to the latest version of name with:
kots pull helm://name 

Unfork should properly handle helm name prefixes

Helm will often add prefixes to the names of generated resources when applying to a cluster - resulting in names like jaunty-quail-redis-master instead of just redis-master. Unfork should handle this (with json patches to change names, if required) when it appears.

unfork should show a message when tiller is not found