api calling back 500 error

[TarlyJQ]

I have encapsulated the Rustful API using the controller runtime myself, but when calling it, there will be an error
admission webhook "promotion.kargo.akuity.io" denied the request: Stage "dev" in namespace "multi-frontend-app" defines no promotion steps

[krancour]

Technically, we're not really supporting curling the API server just yet. We intend to soon.

The practical barrier, at this time, is that there is not yet a way to generate any long-lived credentials for the Kargo API server. i.e. There's no such thing as a Kargo "service account" yet, although I anticipate there will be at some point soon. Until then, there isn't a practical way to obtain credentials for interactions via curl. I presume that to authenticate this request, you've logged into the API server with the kargo CLI or UI to obtain your personal, short-lived bearer token and you're using that? (Or you've done something else equally hacky?) Obviously, this isn't how we'd like to instruct people to go about doing things.

All that said, I can offer some small bit of guidance here, but it's not a rabbit hole I want to fall too deep into. I'm not sure you're more focused on the error message you're receiving or the fact of having received a 500 where a 400 would seem more appropriate.

The error message is easily explained. A Stage with no promotion steps defined is a "control flow stage". Promoting to a control flow stage is meaningless and therefore not permitted.

As for the 500 which seems as if it should be a 400, the error is being issued from a Kubernetes mutating webhook (also known as a "defaulting webhook"). The role of this component is not to validate inbound requests, but to apply any defaults or other mutations that are required in order for the request to be valid when it reaches the validating webhook, whose job it is (as implied by its name) is validating the inbound request. Kubernetes always invokes webhooks in this order -- defaulting webhooks and then validating webhooks.

As noted, the error is being returned from a defaulting webhook and it's doing so because the request is invalid to the extent that the defaulting webhook can not actually proceed with what it's supposed to do.

I am uncertain as to whether we have any control over the error code under those conditions. It's possible, on account of validation not being a defaulting webhook's job, that controller-runtime isn't giving us this flexibility. It is possible that framework assumes all errors from a defaulting webhook to be internal errors.

If this is not true, we can perhaps fix this and return a 400 instead. If it is true, I think we can fix it differently by allowing the defaulting webhook to return an immediate "success" under these conditions so that the request will reach the validating webhook, which does give us more fine-grained control over response codes (by using different error types).

One way or another, I think we can make this return the correct code.

I will open an issue for this.

[krancour]

I'm going to close this, since I believe the questions is answered and the small amount of work that is actually to be done is now tracked in an issue: #5044.

[TarlyJQ]

Thank you for the incredibly clear explanation — it's been extremely helpful to understand both the root cause (control flow stage limitation) and the webhook behavior nuances.

I tried removing the Kargo ValidatingWebhookConfiguration from the cluster, but it didn’t resolve the issue (likely due to the defaulting webhook’s role in the pipeline). As a temporary workaround, I’ve built a thin Rust-based client wrapper around the Kargo CLI to handle the API interactions, which has successfully unblocked my work for now.

I truly appreciate your guidance and will keep an eye on the issue you’re opening for the error code fix. Thanks again for your time and expertise! 🙏

[krancour]

I tried removing the Kargo ValidatingWebhookConfiguration from the cluster

fwiw, none of the webhooks are optional. They are essential for Kargo to function correctly.