search

drasi-project / drasi-platform

The Data Change Processing platform
https://drasi.io/
Apache License 2.0
1.01k stars 33 forks source link

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

Open markjgardner opened 4 days ago

markjgardner commented 4 days ago

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: https://github.com/drasi-project/drasi-platform/blob/cd2f793d67468c2f8993682c5b140a022c0133b3/cli/service/installer.go#L625

Would you like to support us?

markjgardner commented 4 days ago

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 commented 4 days ago

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 commented 3 days ago

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 commented 3 days ago

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.