initial project move from kudo into its own project

[kensipe]

There are a number of issues that need to be resolved however this move most of kudo test harness into its own project as kuttl

Changes:

1. The create-or-update integration test used to install / update an instance kind which is kudo specific and it has been removed.
2. TestWaitForCRDs was a kudo specific test and was removed

Todos:

[] harness.go used to have a RunKUDO function. It has been removed but we need a way from KUDO (or other project) to initial the cluster (for instances with it's CRDS etc.)
[] test type defines StartKUDO bool json:"startKUDO"`` which should be removed
[] document this new project on how to use it (especially with above changes)
[] modify kudo to use this project.
[] document that kubebuilder is required with etcd in the path (fails otherwise)

This project infra supports 1) gen from test type, 2) lints with same standards as other kudobuilder projects, 3) make test and make integration-test work

Considerations:

1. do we need a CLI to execute? or does all users of this lib create their own? I am expecting to have kudo test command which will integrate into this project. That said... it would be nice to be able to run tests with cli.

Signed-off-by: Ken Sipe kensipe@gmail.com

[gerred]

yeah we should bring this out into it's own binary, if we want to keep kudo test then we'll just call out to kuttl.Init or whatever that code path is over from the kubectl kudo CLI, so we can bind a version of kuttl to a version of kudo test.

[gerred]

Another consideration - do we want to turn the provisioning/usage of external clusters into data, rather than using KIND? We don't need to solve that by any means in this PR, but it would result in removing the startKIND section. though IMO I kind of like having KIND as a nice built-in default for development, and then coming up from a data format of "bring your own cluster!"

[gerred]

@jmccormick2001

[kensipe]

yeah... with more thought on it... I think having an executable CLI makes sense here

[gerred]

yeah... with more thought on it... I think having an executable CLI makes sense here

plus then when we make it a kubectl plugin it's kubectl kuttl - or kube cuttle cuttle. ;)

[ANeumann82]

Looks good for the initial commit. Maybe we should extract the TODOs from the PR into separate issues?

[gerred]