Unable to apply manifest to cluster

AnthonyDeveloper77 commented 5 months ago

🔥 Bug Description

I can successfully init and generate the manifest, and I can see the images pushed to docker hub, however, when I apply, I get the below error message.

Would you like to deploy the generated manifests to a kubernetes cluster defined in your kubeconfig file? [y/n] (y): y (?) Done: Successfully set the Active Kubernetes Context to 'docker-desktop' (!) Failed to apply manifests to cluster. (!) Error: Value cannot be null. (Parameter 'path1')

I tried to apply to docker-desktop, minikube and AKS, and the result is same.

It worked fine last week, but not anymore. I presume, some local configuration that I was fiddling with caused this issue, but I can't figure what it is.

🔍 Steps to Reproduce the Bug

Create the Aspire solution in VS 2022,
Execute aspirate init and set the container registry
Execute aspirate generate which generates the manifest, and image is pushed to the container registry (docker hub)
Execute aspirate apply and select the kubernetes cluster from the kubeconfig file
after a few second it returns the above error message.

🧯 Possible Solution

Usefull tips or places to start go here.

prom3theu5 commented 5 months ago

Would you be able to share the generated manifest.json file please (not aspirate state!) I can then drop it into my test harness

I'll replicate the setup, and use docker hub too. It sounds like there is an issue in generation of the imagePullSecret which gets loaded into k8s to allow your docker credentials to be used.

The docker PAT you are using definitely has read rights?

Lubendo commented 4 months ago

Hi, do you have any update on this issue? I was unsuccessfully trying this the whole day with the Aspire Starter solution and had no luck. Please find enclosed my manifest.json. Thank you.

Would you like to deploy the generated manifests to a kubernetes cluster defined in your kubeconfig file? [y/n] (y): y (?) Done: Successfully set the Active Kubernetes Context to 'docker-desktop' (!) Failed to apply manifests to cluster. (!) Error: Value cannot be null. (Parameter 'path1')` manifest.json

chrisgodfrey commented 4 months ago

Experiencing the same issue here. Curiously it did work once, but since then I've consistently been getting the same error message as above. I have tried standing up a local docker registry first. As per the OP I can see my image pushed there in the catalog before it fails.

Does 'path1' refer to the image? I couldn't find a reference for this in the code, looks like it's coming from outside Aspirate?

prom3theu5 commented 4 months ago

Sorry I'm on Holiday atm till the 3rd of August I will get on it straight away when back

chrisgodfrey commented 4 months ago

The problem seems to be related to the state management during the process. When opting to not reuse the previous state values by answering 'no', the apply command fails, indicating a potential issue with the state being malformed. This is indicated by the message "state has been disabled for this run" and a subsequent path1 = null error, which does not occur when reusing the previous state values by answering 'y'.

The option to not reuse the previous state values seems to lead to a dead end. If the successful execution of the command depends on reusing the previous state, it's unclear why the question is asked.

This also affects the ability to deploy the same generated Kubernetes configurations to different clusters without regenerating each time, as the last question in the sequence asks for the cluster deployment target. While this can be accounted for once known, it's an additional step that ideally would be avoided as each generate takes a while to complete.

I’ve been able to consistently replicate this behaviour across multiple runs with the following sequence:

azd init azd up azd down aspirate init aspirate generate aspirate apply

When choosing to reuse previous state values with 'y', the apply command succeeds.
When choosing not to reuse previous state values with 'n', the apply command fails, and appears to corrupt the state, necessitating a rerun of 'aspirate generate' before attempting again.

Interestingly, creating & deploying a brand new 'empty' Aspire project doesn't seem to hit this issue. Our project stands up some additional services, so it might be that this affects the state handling in an unexpected way?

siemandelc commented 2 months ago

Any updates to this issue? I'm also encountering this.

jmair17 commented 1 month ago

Any update?

prom3theu5 / aspirational-manifests