Use of kustomize appears to prevent the use of operator-sdk

[dhellmann]

The changes started in 4c170b0 to add kustomize support seem to have broken the operator-sdk code generator, so adding a new API version to fix #434 is going to be harder.

$ operator-sdk add api --api-version metal3.io/v1beta1 --kind BareMetalHost
INFO[0000] Generating api version metal3.io/v1beta1 for kind BareMetalHost.
INFO[0000] Created pkg/apis/metal3/group.go
INFO[0000] Created pkg/apis/metal3/v1beta1/baremetalhost_types.go
INFO[0000] Created pkg/apis/addtoscheme_metal3_v1beta1.go
INFO[0000] Created pkg/apis/metal3/v1beta1/register.go
INFO[0000] Created pkg/apis/metal3/v1beta1/doc.go
INFO[0000] Created deploy/crds/metal3.io_v1beta1_baremetalhost_cr.yaml
FATA[0000] Failed to update the RBAC manifest for the resource (metal3.io/v1beta1, BareMetalHost): (failed to read role manifest /home/dhellmann/go/src/github.com/metal3-io/baremetal-operator/deploy/role.yaml: open /home/dhellmann/go/src/github.com/metal3-io/baremetal-operator/deploy/role.yaml: no such file or directory)

The role file has been moved

$ find deploy/ -name role.yaml
deploy/rbac/role.yaml

[dhellmann]

/cc @Xenwar

[kashifest]

@dhellmann is it not possible to instruct operator-sdk to use deploy/role.yaml instead?

[dhellmann]

@dhellmann is it not possible to instruct operator-sdk to use deploy/role.yaml instead?

The problem is it wants deploy/role.yaml but the file is now deploy/rbac/role.yaml. We could, possibly, tell the SDK to change all of the files it produces, but I don't think that's what we want to do.

The SDK output is how we manage the generated code. The kustomize files are one particular way to deploy that code.

Ideally the kustomize stuff would be in its own repository, since there are going to be other opinionated ways to deploy (OpenShift has a different way, for example). But it's fine with me to keep everything here in this repository for convenience, as long as we don't have the tools fighting with each other over who owns which files.

[kashifest]

deploy/rbac/role.yaml

Sorry my mistake, I meant is it not possible to instruct operator-sdk to use deploy/rbac/role.yaml

[dhellmann]

deploy/rbac/role.yaml

Sorry my mistake, I meant is it not possible to instruct operator-sdk to use deploy/rbac/role.yaml

The point is that the contents of the deploy directory are owned by the operator-sdk. It generates those files and does not expect anything else to be moving them around or heavily modifying them.

Is there a technical reason for us to have the kustomize versions of the files also under the deploy directory?

[kashifest]

Nope. It was a curious query. I was thinking would it be a good idea to keep multiple copies of same files in different locations and then it would also require back-porting the changes from one to the other (whenever there is any). Instead I am thinking if we can keep those files which operator-sdk needs in deploy/ folder instead of their own subdirectories and still use the same for kustomize. Kustomize is not modifying deploy/rbac/role.yaml by the way.