chore: update project structure

[ramizpolic]

Overview

Resolves #44

Notes for reviewer

Uses new paths for various resources, given as:

├── deploy
│   ├── charts - defines helm chart resources
│   ├── defaults - defines resources required to run examples/operator tests
│   ├── dev - defines various development env deployment scripts
│   │   ├── microk8s - example deployments for microk8s env
│   │   └── multi-dc - deployment scripts for running vault instances across multiple clusters for local and AWS envs
│   └── examples - defines example resources for deploying operator
├── hack
│   └── scripts

Also, all custom resources in deploy/examples dir have been moved to independent files which define complete examples.

[sagikazarmark]

Couple notes:

• I'd much rather split this up into smaller PRs
• deploy/crd is not quite right: those are rather CR examples
• deploy/test move doesn't feel right, especially since it's gonna be rewritten at some point in the style of the vault-secrets-webhook e2e tests
• Can't find deploy/files anywhere yet there are references to it in code

[ramizpolic]

In that case, I'd recommend using config directory (similar to how kubebuilder does CRD generation) which can be a common parent to all the mentioned resources.
I could split into multiple PRs, but I feel it won't really matter as much since only a couple of tree changes are impactful.

[sagikazarmark]

In that case, I'd recommend using config directory (similar to how kubebuilder does CRD generation) which can be a common parent to all the mentioned resources.

That doesn't feel quite right either. I mean, not for all (eg. tests).

Here is my recommendation:

• deploy/charts/...
• deploy/examples -> CR examples
• deploy/examples/base (?) -> base resources (rbac) for examples
• deploy/examples/... -> additional directories for examples with multiple resources (alternatively: put different objects into one yaml file for these examples)

[ramizpolic]

In that case, I'd recommend using config directory (similar to how kubebuilder does CRD generation) which can be a common parent to all the mentioned resources.

That doesn't feel quite right either. I mean, not for all (eg. tests).

Here is my recommendation:

• deploy/charts/...
• deploy/examples -> CR examples
• deploy/examples/base (?) -> base resources (rbac) for examples
• deploy/examples/... -> additional directories for examples with multiple resources (alternatively: put different objects into one yaml file for these examples)

Adding to this, if we were to put scripts to hack/scripts, we could also then move tests to hack/tests, which would fit more clearly. I wanted to avoid deploy dir since it is used as a transient dir during resource generation.

[sagikazarmark]

Adding to this, if we were to put scripts to hack/scripts

Sounds good to me

we could also then move tests to hack/tests

Let's not touch tests for now. As I said, I wanna move them to e2e (which is another loosly applied pattern out there) once we rewrite them using the e2e framework.

I wanted to avoid deploy dir since it is used as a transient dir during resource generation.

deploy is a widely used pattern IMO. I generally prefer it over config.

[akijakya]

I left some comments but otherwise LGTM 💯

[sagikazarmark]

Couple more nits. Other than those, LGTM.

[sagikazarmark]

LGTM thanks @ramizpolic

Nice work!