Unable to apply manifest to cluster

[AnthonyDeveloper77]

🔥 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

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

🧯 Possible Solution

• Usefull tips or places to start go here.

[prom3theu5]

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]

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]

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]

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

[chrisgodfrey]

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]

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

[jmair17]

Any update?

[GabrieleMessina]

Hi there! I think this issue might be affecting quite a few folks trying to get started with Aspirate and Aspire, it appears on a "simple" command that many expect to work smoothly. Resolving this could really help make the onboarding experience even better. Really appreciate all the effort you’re putting into this project!

[John-Leitch]

I've managed to achieve repro, in part due to @chrisgodfrey's observations. Let me see if I can get this sorted and submit a PR.

[John-Leitch]

The NullReferenceException is in the IPath.Combine call made in KustomizeService.WriteSecretsOutToTempFiles. ApplyOptions does not have OutputPath, so it can only come from deserialized state. Otherwise, the value is null, causing the exception discussed above. I will try to get a PR out for this over the weekend.

[SpongeManiac]

Looks like that vacation is running a little long, don't you think? Please merge this pull request, it has been an active issue for a year, and this pull request was created 4 months ago. I would be more understanding if your project wasn't listed as the official solution for taking Aspire to K8s under MS documentation. It is a shame that this repo is unmaintained and seemingly ignored. I cannot move forward with my POC because of this issue.

Maybe if you do not feel like maintaining this repo, you should hand it off to someone else?