Couldn't daprized apps with SpinApp kind

[thangchung]

I'm upgrading the works at https://dev.to/thangchung/how-to-run-webassemblywasi-application-spin-with-dapr-on-kubernetes-2b8n

And currently, I follow the guidance at https://github.com/spinkube/documentation/blob/running-with-dapr/content/en/docs/spin-operator/tutorials/running-with-dapr.md, and spinkube/documentation#29

Everything is okay, but when I use SpinApp kind as below

kubectl apply -f - <<EOF
apiVersion: core.spinoperator.dev/v1alpha1
kind: SpinApp
metadata:
  name: product-app
  annotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "product-app"
    dapr.io/app-port: "80"
    dapr.io/enable-api-logging: "true"
spec:
  image: "ttl.sh/coffeeshop-product-api-spin:24h"
  executor: containerd-shim-spin
  replicas: 1
EOF

When I checked the status:

> kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
my-redis-master-0              1/1     Running   0          28m
product-app-77c56df659-97z8w   1/1     Running   0          8m48s

Only one container is running. That means dapr couldn't run the daprized process on this deployment.

But when I use the same approach in my article as below

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: product-api
  template:
    metadata:
      labels:
        app: product-api
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "product-api"
        dapr.io/app-port: "80"
        dapr.io/enable-api-logging: "true"
    spec:
      runtimeClassName: wasmtime-spin-v2
      containers:
      - name: product-api
        image: ttl.sh/coffeeshop-product-api-spin:24h
        command: ["/"]
        env:
        - name: RUST_BACKTRACE
          value: "1"
        resources: # limit the resources to 128Mi of memory and 100m of CPU
          limits:
            cpu: 100m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 128Mi
EOF

And

> kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
my-redis-master-0              1/1     Running   0          28m
product-api-f97b984f-6dnl9     2/2     Running   0          16m

Look at the 2/2 containers, I think it is a bug of spin-operator, or might I do something wrong? Could anyone shed some light on it? Thank you very much.

[endocrimes]

I think this might be a documentation bug - we don't copy annotations from the SpinApp itself - but let you provide Pod, Service, and Deployment annotations as part of the Spec -

spin-operator/api/v1alpha1/spinapp_types.go

Lines 69 to 76 in 52546a5

	// ServiceAnnotations defines annotations to be applied to the underlying service.
	ServiceAnnotations map[string]string `json:"serviceAnnotations,omitempty"`
	// DeploymentAnnotations defines annotations to be applied to the underlying deployment.
	DeploymentAnnotations map[string]string `json:"deploymentAnnotations,omitempty"`
	// PodAnnotations defines annotations to be applied to the underlying pods.
	PodAnnotations map[string]string `json:"podAnnotations,omitempty"`

[calebschoepp]

@endocrimes just beat me to it 😄. And yep it looks like the docs are incorrectly setting the annotations on the SpinApp CR itself and not on the underlying resources.

[thangchung]

@endocrimes @calebschoepp it worked as the suggestion from you guys

apiVersion: core.spinoperator.dev/v1alpha1
kind: SpinApp
metadata:
  name: product-app
spec:
  image: "ttl.sh/coffeeshop-product-api-spin:24h"
  executor: containerd-shim-spin
  podAnnotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "product-app"
    dapr.io/app-port: "80"
    dapr.io/enable-api-logging: "true"
  enableAutoscaling: true

Thanks. I closed it for now.

[bacongobbler]

I’m going to reopen this as an action item to fix the docs. Thanks for the report!

[bacongobbler]

Fixed in spinkube/documentation#29. Thanks everyone!