Suggestions for deployment

[kawaja]

This is an awesome idea – well done on the work so far!

I'm going to make a bit of a drive-by suggestion after a brief attempt at using the operator. Please feel free to ignore it – it's your project.

To make this project more appealing to general users:

• I haven't fully absorbed the architecture but, based on my previous experience, I'd expect nothing should need to be "built" on the user's workstation if they're going to use the quay.io containers.
• Develop a deployment mechanism which does not require installation (whether manual or automated) of any development tools (such as make, golang, controller-gen). These are not friendly for CI/CD / composable infrastructure pipelines.
• Don't assume that the user of this tool is a developer. Most users would be cluster/network/system administration type people. (e.g. when I run make deploy I get an obscure error – obscure for me, a non-go developer – can't load package: package sigs.k8s.io/controller-tools/cmd/[email protected]: can only use path@version syntax with 'go get'. This is not something I'm particularly looking forward to debugging, given I was expecting to see YAML manifest files.
• Avoid opinionated use of optional kubernetes tools, specifically kustomize. While the tool looks pretty cool, not everyone will have it installed. kubectl apply -k would be better (since everyone will already have it), but ideally it would be optional.
• The user should be able to inspect the manifests before they're deployed. While I can see a lot of YAML files, it's not clear which ones are used and how. In particular, the user should be able to decide which namespace to use to fit with local practices.
• Rook's approach works fairly well, with a set of example manifests and instructions on how to use them (see https://rook.github.io/docs/rook/latest/quickstart.html). Then once playtime is over, the administrator can choose to manage the manifests however they want. I like the idea to consider putting the samba-operator under the rook umbrella – I think it would be a good fit.

For now, I'm using the container with manual configuration.

[phlogistonjohn]

Thank you very much for the feedback! A lot of these issues are due to the relative youth of he project and our (mostly my) assumption that people wanting to use the operator also want to hack on it. :-)
Adding more non-developer focused docs and deployment methods are certainly an important step toward getting the project more mature.