Description
Currently, the azure-init main flow in main.rs tightly couples provisioning logic with reporting success or failure to the health endpoint. Specifically:
- On provisioning success,
report_ready() is called immediately.
- On provisioning failure,
report_failure() is called immediately.
- Configuration load errors trigger
report_failure() inline.
This design makes reporting dependent on provisioning, which limits flexibility for future enhancements such as exposing APIs for report_ready and report_failure.
Problem
- Reporting logic is embedded directly in the main provisioning flow.
- Cannot invoke
report_ready or report_failure independently of provisioning.
- Harder to support external consumers or APIs that need reporting without full provisioning.
Solution
- Remove inline calls to
report_ready() and report_failure from main.rs.
- Update
Provision::provision() to return status without forcing reporting.
Relevant Code
The current coupling occurs in main.rs:
match provision(config, &vm_id, opts).await {
Ok(_) => {
let report_result =
report_ready(&clone_config, &vm_id, None).await;
.....
ExitCode::SUCCESS
}
Err(e) => {
...
let report_result =
report_failure(report_str, &clone_config).await;
....
tracing::error!("Provisioning failed with error: {e:?}");
....
}
}
}
Description
Currently, the
azure-initmain flow inmain.rstightly couples provisioning logic with reporting success or failure to the health endpoint. Specifically:report_ready()is called immediately.report_failure()is called immediately.report_failure()inline.This design makes reporting dependent on provisioning, which limits flexibility for future enhancements such as exposing APIs for
report_readyandreport_failure.Problem
report_readyorreport_failureindependently of provisioning.Solution
report_ready()andreport_failurefrommain.rs.Provision::provision()to return status without forcing reporting.Relevant Code
The current coupling occurs in
main.rs: