Update helm-app-operator-kit to use controller-runtime

[joelanford]

There has been significant effort to transition operator-sdk to use controller-runtime (https://github.com/kubernetes-sigs/controller-runtime).

See the refactor/controller-runtime branch: https://github.com/operator-framework/operator-sdk/tree/refactor/controller-runtime

This operator is currently based on the "previous" operator-sdk scaffolding and APIs, which will soon be deprecated in favor of the controller-runtime updates.

I'm working on a PR for this work, but would like to open this up for discussion and planning.

@hasbro17 - Is the refactor/controller-runtime branch sufficiently ready to be used as a basis for scaffolding out a new version of this operator?

[alecmerdler]

A PR would be greatly appreciated; I have no knowledge of how to upgrade scaffolding created from an older version of the Operator SDK.

[hasbro17]

@joelanford We might tweak the templates and the CLI slightly in the coming days but you should be able to use it to scaffold a new controller-runtime based project.

Since we don't have a migration strategy figured out right now I would suggest doing a clean start.

$ mv helm-app-operator helm-app-operator-old
$ operator-sdk new helm-app-operator
$ operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=HelmApp
$ operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=HelmApp

However that would only get you started with a typical controller that watches and reconciles for that exact APIVersion and Kind resource.
I have to take a closer look at how the helm-app-operator works but I think it's significantly different.

The sdk.Watch() can dynamically watch for any apiversion and kind as the helm-operator currently does:

resource := os.Getenv(APIVersionEnvVar)
kind := os.Getenv(KindEnvVar)
sdk.Watch(resource, kind, namespace, resyncPeriod)

However the default controller generated above would watch for that specific kind:

err = c.Watch(&source.Kind{Type: &appv1alpha1.HelmApp{}}, &handler.EnqueueRequestForObject{})
if err != nil {
	return err
}

I haven't tried it out myself yet but I think the controller runtime should support watching a type dynamically using Unstructured objects controller-runtime #101:

helmApp := &unstructured.Unstructured{}
helmApp.SetGroupVersionKind(schema.GroupVersionKind{
	Group:   <group from APIVersion env var>,
	Version: <version from APIVersion env var>,
	Kind:    <kind from Kind env var>,
})

err = c.Watch(&source.Kind{Type: helmApp}, &handler.EnqueueRequestForObject{})
if err != nil {
	return err
}

And then the reconcile for the controller would be the same as the ansible-operator where you'd lookup the correct unstructured object(by setting its gvk) from the cache.
https://github.com/operator-framework/operator-sdk/blob/master/pkg/ansible/controller/reconcile.go#L47-L49

Of course this will affect #41 as well. I'll need to take a closer look at the helm-operator to give this some more thought.

[joelanford]

That makes sense to me and is the path I'm going down. I've got an initial version working that also covers #41. As it turns out, it may just be easier to fold those together into the same PR, which should be coming this afternoon.

I anticipate there will be more changes and tweaks, but I figured it would be easier if we have something concrete to discuss.

[joelanford]

I've fixed a few minor issues in PR #43. I believe it is now ready for review.

I attempted to organize the pkg/helm package similarly to the pkg/ansible package in operator-sdk to make it easy to pull into operator-sdk when we're ready. As a result, I think the PR is bigger than it necessarily has to be. If it makes more sense, I can reorganize with a focus on minimizing changes.

[joelanford]

This issue is closed by PRs #45, #46, and #47