Operator cleanly exits in non-existent CRD

[ccronca]

This prevents operator panics if it starts before creating the CRD

Fixes #183

[openshift-ci-robot]

Hi @camilocot. Thanks for your PR.

I'm waiting for a operator-framework member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[allamand]

Why we won't let the Operator create it's CRD in case it is missing ?

[ccronca]

@allamand It was already discussed on the issue #183

@bradbeam This won't always work in production use cases because installing the CRD requires cluster-level permissions, but running the operator in a namespace only requires permissions in that namespace. Some installations will require the CRD to be installed by a more privileged user than the person who is actually using the operator.

[hasbro17]

@camilocot Sorry for the late review.
Let's just log the error and exit cleanly with os.Exit(1) for all errors. That's much simpler.
I'm not sure of the benefit of only exiting for non-existent CRD and panic for other errors.

[hasbro17]

@camilocot Can you please rebase your changes with the master first.
We're have to source your PR branch in our e2e test(to properly resolve dependencies) and there's been some changes to the k8s deps since then. We're on 1.11 now.
https://github.com/camilocot/operator-sdk/blob/feature/exit-crd-inexistent/Gopkg.toml#L11-L23
https://github.com/operator-framework/operator-sdk/blob/master/Gopkg.toml#L11-L23

[ccronca]

@hasbro17 rebase is done, is something else missing?

[estroz]

@camilocot we made a fairly large change to master today; instead of rebasing, I would recommend creating a new branch, doing a git checkout --hard master on the old branch, then cherry-picking this commit onto your old branch from new. Thanks!

[hasbro17]

@estroz Actually after the rebase we won't have this issue anymore. We don't even have pkg/sdk/api.go anymore.
The runtime's manager exits cleanly if a controller fails to watch a resource that's not registered.

2018/10/16 16:20:16 Go Version: go1.10.2
2018/10/16 16:20:16 Go OS/Arch: darwin/amd64
2018/10/16 16:20:16 operator-sdk Version: 0.0.6+git
2018/10/16 16:20:16 Registering Components.
2018/10/16 16:20:16 no matches for kind "Memcached" in version "cache.example.com/v1alpha1"
exit status 1
2018/10/16 16:20:16 failed to run operator locally: exit status 1

@camilocot We've replaced the SDK apis with the controller-runtime on the master so this should be fixed. We'll have a release out soon that will include this fix.