drasi install fails if dapr install isn't named "dapr"

[markjgardner]

Steps to reproduce

Install the managed extension on AKS and name the installation dapr-ext
az k8s-extension create --cluster-type managedClusters --cluster-name mycluster-aks --resource-group myaks-rg --name **dapr-ext** --extension-type Microsoft.Dapr --auto-upgrade-minor-version false

Observed behavior

If you have installed dapr using a name other than dapr the drasi install fails because it doesn't recognize that dapr is already installed and then tries to install it again, colliding with existing resources:

$ drasi init -n drasi
Installing Drasi with version 0.1.6 from registry ghcr.io
ℹ Dapr not installed
✗ Error intalling Dapr: Unable to continue with install: ServiceAccount "dapr-injector" in namespace "dapr-system" exist
Error: Unable to continue with install: ServiceAccount "dapr-injector" in namespace "dapr-system" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "dapr": current value is "dapr-ext"

Desired behavior

User should be able to indicate that dapr is already installed or specify the name used during install so that installation can be correctly detected by the drasi install process.

Workaround

Reinstall dapr on the cluster, making sure to name it dapr

Drasi Version

$ drasi version
Drasi CLI version: 0.1.6

Operating system

Ubuntu 22.04

Additional context

I believe this hardcoded label selector is the problem:

drasi-platform/cli/service/installer.go

Line 625 in cd2f793

LabelSelector: "app.kubernetes.io/name=dapr",

Would you like to support us?

• Yes, I would like to support you

[markjgardner]

As an alternative, maybe the label app.kubernetes.io/part-of: "dapr" would be a better option as it should be more consistent across clusters and different installs?
https://github.com/dapr/dapr/blob/master/charts/dapr/values.yaml#L85

[markjgardner]

In testing this change there appears to be some really tight coupling between drasi and dapr (specifically 1.9.0). Can someone explain why that is before I go and try ripping all of that stuff out?

[ruokun-niu]

Hi @markjgardner , thanks for creating this issue. When we developed the CLI back in 2023, we encountered some kinds of serialization issues with the latest version of dapr back then, so we set the sidecar image version to be fixed at 1.9.0. As a result, we also had to fix the dapr runtime version to be at 1.10.0 (since the runtime needs to be within one minor version of the sidecar).

I tried to do a Drasi install with dapr version 1.14.4 (the latest at the moment), but I was unable to successfully install everything (logs: https://gist.github.com/ruokun-niu/73eb91ed6a84e9621f433c71176bf328). I have a created a task on our board for investigating why this is happening. However, I think for the short term we are stuck with 1.9.0.

[ruokun-niu]

As an alternative, maybe the label app.kubernetes.io/part-of: "dapr" would be a better option as it should be more consistent across clusters and different installs? https://github.com/dapr/dapr/blob/master/charts/dapr/values.yaml#L85

I do think this is a better approach for verifying an existing dapr installation.

[ruokun-niu]

Hi @markjgardner , just checking in to see if there's anything you need from us?

[markjgardner]

@ruokun-niu I'm not actively working on this issue at the moment. It's still in my backlog, I've just been distracted with other priorities recently. I'll let you know when I get started. Or if someone else has capacity and wants to pick this issue up now, I'm happy to share what I know.