mini-langstream start hangs after HerdDB - service langstream/langstream-control-plane has no node port

[Gagravarr]

I'm trying to follow https://docs.langstream.ai/installation/get-started-minikube to get langstream running on minikube. I installed the dependencies, ran the get shell script, then tried to start. However, mini-langstream start hangs after HerdDB: ✅

It seems to be stuck in the start_port_forward step - https://github.com/LangStream/langstream/blob/main/mini-langstream/mini-langstream#L227

In /tmp/ I can see the file it is stuck grep'ing, which shows

* service langstream/langstream-control-plane has no node port

There's no error handling in start_port_forward so the script hangs forever if there's no URL returned...

It looks like the services have been defined without external ports

mini-langstream kubectl get svc
NAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
langstream-api-gateway     ClusterIP   10.106.115.58    <none>        8091/TCP   48m
langstream-control-plane   ClusterIP   10.111.103.230   <none>        8090/TCP   48m

Not sure if there's a missing setup step in the docs, a missing config step in the mini-langstream script, or a bug in the helm script?

[eolivelli]

Are you on Linux?

@nicoloboschi can you please take a look?

[Gagravarr]

Yup, linux, running Ubuntu 22.04.3 LTS (newly setup Azure VM today)

[Gagravarr]

In case it helps, the versions of everything I'm running are:

*Docker:* Docker version 24.0.5, build 24.0.5-0ubuntu1~22.04.1
*Minikube:* minikube version: v1.31.2
*Helm:* version.BuildInfo{Version:"v3.13.1", GitCommit:"3547a4b5bf5edb5478ce352e18858d8a552a4110", GitTreeState:"clean", GoVersion:"go1.20.8"}
*KubeCtl:* Client Version: v1.28.3, Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
*Ubuntu:* Ubuntu 22.04.3 LTS
*LangStream:* LangStream CLI 0.4.2
*Mini LangStream:* 0.4.2

Running the wrapped minikube we see no node ports setup for the langstream services, but ingress is enabled in general

KUBECONFIG=.mini-langstream/data/kube-config minikube --profile mini-langstream service list
|---------------|------------------------------------|--------------|---------------------------|
|   NAMESPACE   |                NAME                | TARGET PORT  |            URL            |
|---------------|------------------------------------|--------------|---------------------------|
| default       | kubernetes                         | No node port |                           |
| ingress-nginx | ingress-nginx-controller           | http/80      | http://192.168.49.2:30413 |
|               |                                    | https/443    | http://192.168.49.2:32229 |
| ingress-nginx | ingress-nginx-controller-admission | No node port |                           |
| kube-system   | kube-dns                           | No node port |                           |
| langstream    | langstream-api-gateway             | No node port |                           |
| langstream    | langstream-control-plane           | No node port |                           |
|---------------|------------------------------------|--------------|---------------------------|

[Gagravarr]

From my investigations so far, it does seem like helm isn't setting up the external node port that the script is expecting

I'm still not sure if there's an issue with the latest helm script, the minikube env needs extra services adding that full k8s doesn't, there should be a fallback via the ingress (which is setup fine), or something else!

I have at least got a proposed patch that will detect when this has happened and error out, rather than hanging, which is a start...

[Gagravarr]

Since the Helm charts are shared between the Mini-Langstream case and more "production" deployments, I'm not sure if it's a good idea to define a target port on the k8s service definition in the helm chart as standard. Doing that would make it harder for people using other approaches (eg ingress or gateway) to override things for their own use

I've seen a few other projects setup their helm charts to support a few different modes for allowing access, which can be toggled between, but that might be an overkill.

I'm tempted to have mini-langstream check to see if external access has already been enabled (as now), and if not send in a short bit of yaml to k8s to setup a NodePort. That way, the helm charts don't have to change, anyone doing their own custom config continues as now, but the mini-langstream case gets a sensible clean setup (without the complexity of a full ingress setup, or the brittleness of kubectl port forwards).

Thoughts?