Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
1 task done
markjgardner opened this issue Nov 25, 2024 · 4 comments · May be fixed by #120
Open
1 task done

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

markjgardner opened this issue Nov 25, 2024 · 4 comments · May be fixed by #120
Assignees
@ruokun-niu
Labels
bug Something isn't working

Comments

@markjgardner
Copy link

markjgardner commented Nov 25, 2024 •
edited
Loading

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 markjgardner added the bug Something isn't working label Nov 25, 2024
@markjgardner
Copy link
Author

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 markjgardner linked a pull request Nov 25, 2024 that will close this issue
Draft
@markjgardner
Copy link
Author

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 ruokun-niu self-assigned this Nov 26, 2024
@ruokun-niu
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ruokun-niu ruokun-niu

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add cli flag to enable skipping dapr install markjgardner/drasi-platform
2 participants
@markjgardner @ruokun-niu