Add a developer quick start repository based on kustomize

[tomncooper]

Currently, if a developer wants to take our "event stack" for a spin they have to jump through a lot of hoops and read the docs carefully on several different websites.

This proposal recommends creating a centralized Kustomize-based repository within the StreamsHub GitHub organization that provides a unified quick-start experience for deploying the event-streaming stack on a local Kubernetes cluster.

The repository would allow developers to install the full stack; including Strimzi, Kafka, Apicurio Registry and StreamsHub Console, using only kubectl, with no additional tooling required.

It should be noted that this proposal is not about recommending a production deployment method. It is not about providing a mechanism to cover all possible deployment configurations, upgrade paths or security setups. This proposal is about providing the lowest resistance way to deploy a minimum viable event-streaming infrastructure stack. However, in future, we may provide a more comprehensive stack deployment method using one of the approaches discussed in the rejected alternatives section.
This would, of course, be covered by a separate proposal.

[Frawless]

Does this proposal covers https://github.com/streamshub/streamshub-gitops repo? Because I can imagine a lot of stuff will be the same.

I think we should consider creating of shell script that will handle all necessary calls of kubectl with kustomize (creation + waits) based on well documented users parameters. Trying to force everything to be as simple as possible is not a great way for very complex deployment scenarios that will contains from all of different operators. I think we can easily end-up with failing deployments when we will tell users like:

• run this command for deploy operators
• wait some time (how long?)
• run this command for deploy operands (Keycloak is operand, but Kafka with OAuth requires Keycloak up and running, are we fine with several restart before everything will be reachable and in-sync for work properly?)

[tomncooper]

@Frawless

Does this proposal covers https://github.com/streamshub/streamshub-gitops repo? Because I can imagine a lot of stuff will be the same.

The gitops repo could be the venue for a proper production grade deployment solution, perhaps using one of the rejected alternatives like helm or ansible.

I think we should consider creating of shell script that will handle all necessary calls of kubectl with kustomize (creation + waits) based on well documented users parameters. Trying to force everything to be as simple as possible is not a great way for very complex deployment scenarios that will contains from all of different operators.

I updated the introduction to this proposal to make clear that this proposal is for a low resistance way to deploy a minimum viable event-streaming stack. Not to provide a comprehensive deployment method covering all bases. But the point you make about Oauth is a good one. Maybe that should be excluded as a goal of this proposal and instead be covered by a tutorial (using this dev stack as a base) and/or as goal for a more comprehensive deployment solution.

[tomncooper]

One thing I am keen to avoid is to get bogged down trying to create the "all-singing-all-dancing" stack deployment solution from the start. I would like to create such a thing eventually and it is likely that if we do create a more comprehensive solution that it will replace this quick-start. But right now, we have no easy way for people to use the stack and I would like to rectify that.

[aswinayyolath]

LGTM 👍 ✅

[MikeEdgar]

LGTM, thanks @tomncooper

[Frawless]

I updated the introduction to this proposal to make clear that this proposal is for a low resistance way to deploy a minimum viable event-streaming stack. Not to provide a comprehensive deployment method covering all bases. But the point you make about Oauth is a good one. Maybe that should be excluded as a goal of this proposal and instead be covered by a tutorial (using this dev stack as a base) and/or as goal for a more comprehensive deployment solution.

Sounds good to me.

One thing I am keen to avoid is to get bogged down trying to create the "all-singing-all-dancing" stack deployment solution from the start. I would like to create such a thing eventually and it is likely that if we do create a more comprehensive solution that it will replace this quick-start. But right now, we have no easy way for people to use the stack and I would like to rectify that.

Completely agree. As long as we will go with just quick-start for some default config and let the users enhnance it on their own risk (thanks to kustomize) it should be fine and more prod-ready/complex deployment can be covered by upcoming work or from gitops repo with best-practices.

[tomncooper]

Thanks for the reviews everyone. We have (including myself) 4 approvals from maintainers so this proposal is accepted!