Hacking on OAuth and deploying with Strimzi Kafka Operator

[mstruk]

Signed-off-by: Marko Strukelj marko.strukelj@gmail.com

[mstruk]

One thing to point out maybe is that I refer in the documents to my personal public docker image repository at quay.io: https://quay.io/repository/mstruk/strimzi-dev-cli.

We might consider moving this image to docker.io/strimzi/strimzi-dev-cli.

[scholzj]

@mstruk TBH, I think it is very weird to essentially create a duplicate content to what is in the main stirmzi repo. Idealy you should link there and have here only the OAuth specific things.

[mstruk]

@scholzj If it's duplicate content then that's not great and I agree that ideally I could integrate some of this content into main strimzi repo and point there from here.

The content here has a specific angle to it - namely, focus on rebuilding OAuth support and deploy that with Strimzi Kafka Operator with as little fuss as possible, for developers who may not really want to hack on Strimzi operator, but are specifically interested in figuring out an issue or improving upon OAuth support.

If we try to identify parts that would better fit Strimzi main repo ... Essentially setting up Docker, and Kind depending on your OS and then using strimzi-dev-cli image to not have to install all the tools manually could all be in main repo we just need to identify where exactly to move them.

[scholzj]

I'm flexible - I do not have problem to merge this here ... and yes, I understand the focus here is specific and it would probably need sepaarte document with some notes anyway. So I'm fine with it

If you ask me for my opinion:

• I'm not sure we should have a detauled docs how to install things such as Docker or Minikube etc.. That is hard to maintain, works a bit differently for everyone. It is better to just link to the websites of the projects and have them deal with it.
• Having too sophisticated docs here will mean that it will get outdated quickly. So having as much as possible in the main repo where it has better chance to get maintained would make sense.
• I didn't got any feedback from users that our requirements for the build are too complicated. The only problem was the yq version 2 versus version 3. But apart from that nobody complained. I think our build system is unintuitive to use - people are confused when to use make, when to use mvn etc. But I do not think the builder image solves any of that. So I personally do not see any value in it. If you see it, it would be much better to have it discussed in the main repo and if it is approved integrated there. Otherwise there is a big risk that itmigth get outdated etc. Might be good to for example also ask the IBM team if that would have been helpful for them since they were new the other day as well.

[mstruk]

@scholzj I mostly agree with what you're saying.
Like you point out there are parts here that aren't really specific to OAuth and the main project would benefit by moving them there. I'm working on another PR for the main project.

I also don't want these docs to be sophisticated either. The goal of this PR is precisely to not have sophisticated docs where you have to jump around, losing track, missing steps ... But to have easy to follow step-by-step instructions interspersed with explainers.

With regards to Docker and Kubernetes - they're essentially one-liners to install. The rest is not about installing, but about properly configuring the settings, and with a specific version of locally running Kubernetes in order to make sure the build and deploy instructions that follow actually work. Configuration is necessary, and it needs to be very precise. Leaving it to guesswork would nullify the whole purpose of this PR. But this part should really be in the main project. Also the references to strimzi-dev-cli image. It seems like a neat idea to me, but sure - not everyone may agree.

[tombentley]

Lots of nits, but otherwise LGTM.

[scholzj]

@mstruk I restarted the build which was failed. We should check it tomorrow and merge this if it passed.

[mstruk]

Looks like every time I see the following in the log, the test fails:

WARNING: Docker Image oryd/hydra:v1.0.0 is not on DockerHost and it is going to be automatically pulled.

If image is pre-cached, and available locally the test works. I'll try add docker pull oryd/hydra:v1.0.0 before running the tests. Maybe it fixes the issue.

[scholzj]

Thanks for the PR.