add Preflight Validate API support #4329
Conversation
To assign the process to the job object after we create it, we need the `windows.Handle` that backs the process we started with `os/exec`. This was not exported and so we used some gnarly casting to cast the `os.Process` to a structure we authored that had the same layout of `os.Process` so we could grab the handle property. This is unsafe if the layout of the `os.Process` changes, which it did in Go 1.23. Move to code that doesn't depend on the internals of `os.Process` by using the exported Pid to call `windows.OpenProcess` to get a handle and then pass that along to `windows.AssignProcessToJobObject`.
hemarina
requested review from
ellismg,
wbreza,
vhvb1989 and
weikanglim
as code owners
There was a problem hiding this comment.
What is the expectation for templates with nested deployments? For example, I used our Todo AKS template, specified an invalid K8s version parameter and expected that this would fail at our own preflight check call.
Instead the preflight from azd passes, but then we get a preflight failure during ARM deployment.
Preflight validation check for resource(s) for container service aks-oc3hr2l7nqlee in resource group rg-wabrez-todo-aks-swed failed. Message: Web application routing requires at least Kubernetes 1.22. Details:
(Code: WebAppRoutingUnsupportedK8SVersion)
If it is not going to catch preflight errors on nested deployments I question whether it is valuable to add at this point.
|
@weikanglim @wbreza @vhvb1989 @ellismg Could you take another pass of this PR? |
We have discussed about this matter during standup. This is because of nested deployments with parameters referencing runtime functions are not supported by preflight API. The current changes will help users with their custom templates if they're not using nested resources. Jonny from preflight validate API team is working on the fixes of skipped validation on nested deployment, and he expects to release the fix "sometime within this semester". |
|
Rechecking about the templates with current use case, we might want to wait to merge the PR after preflight team's fix. There're templates like Azure-Samples/cosmos-db-nosql-go-quickstart that directly using |
|
We had discussion about future action of this PR between hold the preflight PR, merge the preflight PR but not refer it until fix is released from preflight team or add it in alpha feature. And we decided to hold the preflight PR and merge it after preflight team released their fix on nested resources. Summary of why we hold the PR: |
Adds support for Preflight Validate API.
the operation failed or was cancelledneeds detailed message azure-sdk-for-go#23350TODO:
Questions
What is Preflight?
Preflight API validates whether the specified template is syntactically correct and will be accepted by Azure Resource Manager. More information on preflight wiki.
Why do we implement Validate API?
There’re two preflight API: Validate API and Deployment API. We implemented deployment API. However, deployment API creates a scenario where specific resource fails at preflight API and stops its deployment where some resources are already created. For example, resources are created at an unsupported location. This will cause more dev-test loop for cleaning resources and re-deploy. Adding Validate API support before provisioning to azure solves this situation.
What are Preflight Validate API limitations?
Example Test Error Message
Standard deployments
Deployment stack