Dropping docker support

[puckpuck]

Should we continue to support docker as a deployment mechanism for the demo?

The demo is well supported in Kubernetes, which provides facilities to showcase several additional capabilities of the OpenTelemetry eco-system which are not supported in docker. There is already a desire to add these capabilities (ie: #606) with several other Kubernetes-specific features being conceptualized (K8s stats receiver, K8s attributes processor, etc) as being added to the demo.

Docker provides a low barrier to entry for local development, and dropping support for it needs to include a solution that continues to facilitate that same low barrier. Several local Kubernetes options exist, but we can't expect developers to have the necessary tooling for these environments ready to go.

How do we keep the barrier to entry low to deploy this demo locally in Kubernetes, without an existing local Kubernetes option already available? What about a developer that may already have Kubernetes setup but not in the flavor we are recommending (Kind vs K3s vs Docker Desktop K8s vs ...)?

[julianocosta89]

what if we move on with the k8s improvements and keep the docker support only for development?
I mean, we could leave only the services and Jaeger/Prometheus in the dockerfile and all the other stuff we only ship on k8s.

In the deployment guide we only say k8s.
And in the development guide we could keep docker.

I'm in the fence here, I do like k8s, but I have to agree with what @dineshg13 mentioned in the SIG meeting.
K8s can bring a tech barrier to the demo, and if we think about it as an entry point to everyone starting with OTel, maybe requiring a k8s cluster (even a local one), can be a bit too much.

[devrimdemiroz]

I as well totally agree with this comment.

Docker itself is also providing Kubernetes within. But a very heavy load for the local dev environment. Nowadays, I am experimenting with development over gitpod-opentelemetry It is impressive in a sense. However, local development is as the name suggests local. We might get used to developing in the cloud may be 😊

Tough decision but it is eventually a maintenance issue. I am unable to judge the maintainer's decisions in any way other than with respect.

[mholttech]

I prefer the ease of running the demo in Docker as there are numerous hurdles to run any type of Kubernetes environment where I work. I'm using the OTEL Demo to showcase OpenTelemetry going into the Elastic Stack and keep it running on a server for demo purposes.

[tsloughter]

https://tilt.dev/ is a nice solution. And skaffold would work for this as well. I've used Tilt for this before so plan to look at setting it up (its been years). I used Tilt's ctlptl (https://github.com/tilt-dev/ctlptl) for installing a kind k8s cluster locally for the first time the other day to try out the demo's helm charts and it was very smooth.

It would be simpler if k8s resources and the code were in the same repo.

But I'd argue keeping the docker compose is still very useful.

[cedricziel]

As a product manager, I'm using the OpenTelemetry Demo app to demo certain functionality with our (Grafana) stack. Demo'ing relies on the idea of quickly bringing this demo, or a customized one up.

I would be disappointed if the project decided to drop the docker-compose stack. It comes at basically 0 cost and can serve as a blueprint on how to build individual services. Keeping docker(-compose), means keeping the project accessible to everyone with a docker socket - which is a significantly lower hurdle than a k8s cluster (yes, I know there are solutions that can ease adoption).

Introducing additional features for k8s is fine, but let's make sure it's a progressive experience and we can still use this demo with the simplest case :)

[svrnm]

+1 for keeping docker-compose