feat(azure): Add Azure Ignition fragment generation by peytonr18 · Pull Request #1264 · coreos/afterburn

peytonr18 · 2026-03-19T17:39:57Z

Summary

This PR adds a render-ignition CLI subcommand to Afterburn that generates Ignition config fragment files from Azure IMDS and OVF metadata. These fragments are written to /etc/ignition/base.platform.d/azure/ during initrd, allowing Ignition to natively merge platform-provided user data (hostname, SSH keys, password) without requiring a custom Ignition config.

Changes

New `render-ignition` subcommand

Added src/cli/render_ignition.rs with clap-derived argument parsing.
Accepts --provider/--cmdline, --render-ignition-dir, and per-feature flags (--hostname, --platform-user, --platform-extensions).
Currently gated to Azure only; other providers bail with an informative error.

Azure fragment generation (`src/providers/microsoft/azure/config.rs`)

generate_hostname_fragment(): fetches hostname via MetadataProvider::hostname(), writes hostname.ign with a storage.files entry for /etc/hostname using a data:,<hostname> URI.
generate_user_fragment(): fetches admin username and SSH keys from IMDS via MetadataProvider, optionally reads adminPassword from OVF (ovf-env.xml on CD-ROM), hashes it with SHA-512, and writes user.ign with a passwd.users entry.

OVF / IMDS source rules

Username and SSH keys are sourced from IMDS.
adminPassword is the only field read from OVF. If present and non-empty, it is SHA-512 hashed and included as passwordHash in the Ignition user fragment. If absent or empty, it is omitted.

Systemd / Dracut integration

New afterburn-ignition-fragment.service unit (dracut module) runs during initrd.
Conditioned on ignition.platform.id=azure.
Runs after network-online.target, before ignition-kargs.service.
Creates the output directory and invokes afterburn render-ignition --cmdline --render-ignition-dir /etc/ignition/base.platform.d/azure/ --platform-extensions.

CLI usage

afterburn render-ignition --cmdline --render-ignition-dir <path> --hostname --platform-user
afterburn render-ignition --cmdline --render-ignition-dir <path> --platform-extensions

Flag	Effect
`--hostname`	Generate `hostname.ign` (`storage.files` entry for `/etc/hostname`)
`--platform-user`	Generate `user.ign` (`passwd.users` entry with username + SSH keys + optional password hash)
`--platform-extensions`	Implies `--hostname --platform-user`

Each feature writes its own standalone fragment file. Missing data (e.g., no hostname available) logs a warning and skips, matching existing Afterburn behavior.

Existing functionality is untouched

The multi subcommand's --hostname=<path> direct-file-write path is unchanged. The afterburn-hostname.service (including its Azure/AzureStack conditions) is not modified.

The CLI design is up for discussion — would love feedback on the flag names, subcommand structure, and overall approach.

gemini-code-assist

Code Review

This pull request introduces support for generating Azure-specific Ignition fragments. The implementation is well-structured, adding a new CLI command, a systemd service for execution, and the core logic for fetching data from IMDS and OVF. The refactoring to share SSH key parsing logic is a good improvement.

I've found one critical issue regarding the systemd service activation which would cause the feature to not work as intended, and one medium-severity suggestion to improve code efficiency and readability. Please see the detailed comments.

prestist · 2026-03-23T15:46:20Z

@peytonr18, I have started looking into the changes, I will add my feedback in the next day or so.

prestist

Overall this looks good! just a few concerns around the CLI design and how the IMDS client is built.

peytonr18 · 2026-03-24T17:30:52Z

@prestist I should have addressed all of your comments - thank you so much for these! I agreed with all of your points and adjusted the logic accordingly.

prestist · 2026-03-25T14:24:05Z

@peytonr18 I will take another pass today! thank you for the quick changes!

prestist · 2026-03-25T15:17:37Z

@peytonr18 we do have some failing lints in the CI and you would need to add an entry to the release notes file in the "upcoming" release notes section. https://github.com/coreos/afterburn/blob/main/docs/release-notes.md

prestist

Quick look over, a few small questions/nits

prestist

From my perspective this looks sane, though I think we still have an ordering issue here, wdyt?

prestist

Thank you for all your work on this! from my perspective it lgtm, I would like @travier 's feedback as well.

No longer relevant

prestist

This looks wonderful thank you @peytonr18. I dont see anything that needs to change outside of a small nit about the commit structure. Since we merge directly into the main branch lets squash and rename some of the commits to follow the repo convention of : (lowercase subsystem, imperative tense). Something
like:

azure: Add render-ignition subcommand for Ignition fragment generation
dracut: Add afterburn-ignition-fragment.service ordered between fetch and disks

Or if you'd prefer to keep more granularity, each commit should at minimum get a subsystem prefix (e.g. azure:, dracut:, cli:).

peytonr18 · 2026-06-30T00:11:43Z

@prestist Should have changed the git commit history based on that suggestion, thanks!

cjp256 · 2026-07-06T19:01:48Z

+            .context("fetching metadata from provider")?;
+
+        if hostname {
+            crate::providers::microsoft::azure::config::generate_hostname_fragment(


this is azure-specific call in cli code. this should be generic to provider

Quick design question: after our offline discussion, ignition.rs holds the Ignition config structs + serialization (with the write_to() method on IgnitionConfig), and the render-ignition CLI keeps small generate_hostname_fragment / generate_user_fragment functions that pull data off the provider and write the fragments.

An alternative would be to move that provider→fragment orchestration onto the MetadataProvider trait as default methods, mirroring the existing write_hostname / write_network_units helpers — e.g.:

// src/providers/mod.rs fn write_hostname_ignition_fragment(&self, output_dir: &str) -> Result<()> { let Some(hostname) = self.hostname()? else { return Ok(()); }; let path = Path::new(output_dir).join("hostname.ign"); IgnitionConfig::hostname_fragment(&hostname).write_to(&path) } fn write_user_ignition_fragment(&self, output_dir: &str) -> Result<()> { // admin_username / ssh_keys / admin_password_hash -> IgnitionConfig::user_fragment(..).write_to(..) }

Do you think the trait-default-method approach would be cleaner/preferred here, or is the current split fine? I'm happy to switch the approach if the trait method seems better - it's a small change either way.

I think defaults defined in the trait would be preferable but I would like to hear @prestist's thoughts on the subject

Move the Ignition fragment types and rendering from the Azure provider into render_ignition and source platform data through the MetadataProvider trait (admin_username, admin_password_hash), and switch the feature flags to opt-out (--disable-hostname-fragment / --disable-user-fragment).

Move the Ignition config structs and serialization into src/ignition.rs with a write_to() method on IgnitionConfig, leaving the provider-to-fragment orchestration in the render-ignition CLI. Signed-off-by: peytonr18 <peytonr18@sbcglobal.net>

prestist · 2026-07-15T19:55:25Z

@peytonr18, this still has my stamp :) from my perspective we should be able to merge.

Rolv-Apneseth

Thanks for working on this @peytonr18 . Mostly LGTM but I have a couple questions and suggestions. Realistically though most are nits and not essential.

Rolv-Apneseth · 2026-07-15T20:01:31Z

+        let platform_user = !self.disable_user_fragment;
+
+        if !hostname && !platform_user {
+            slog_scope::warn!("render-ignition: all fragments disabled, nothing to do");


Suggested change

slog_scope::warn!("render-ignition: all fragments disabled, nothing to do");

warn!("render-ignition: all fragments disabled, nothing to do");

Rolv-Apneseth · 2026-07-15T20:01:41Z

+}
+
+fn generate_hostname_fragment(provider: &dyn MetadataProvider, output_dir: &str) -> Result<()> {
+    let hostname = match provider.hostname()? {


Suggested change

let hostname = match provider.hostname()? {

let Some(hostname) = provider.hostname()? else {

warn!("hostname requested, but not available from this provider");

return Ok(());

};

Rolv-Apneseth · 2026-07-15T20:01:51Z

+        .admin_username()
+        .context("failed to query admin username from provider")?;
+    let username = match username {
+        Some(u) => u,


Suggested change

Some(u) => u,

let Some(username) = username else {

warn!("platform-user requested, but admin username not available from this provider");

return Ok(());

};

Rolv-Apneseth · 2026-07-15T20:02:20Z

+    let password_hash = provider
+        .admin_password_hash()
+        .context("failed to query admin password hash from provider")?;
+


Might be worth checking if any credentials are actually available before writing, WDYT?

Suggested change

if ssh_keys.is_empty() && password_hash.is_none() {

warn!("admin username present but no SSH keys or password; skipping user fragment");

return Ok(());

}

Rolv-Apneseth · 2026-07-15T20:02:45Z

+
+    /// Minimal generic provider used to exercise the fragment generators
+    /// without any platform-specific plumbing.
+    struct FakeProvider {


Some of the boilerplate below could potentially be cut down with a #[derive(Default)], e.g.

let provider = FakeProvider { hostname: Some("myhost".into()), ..Default::default() }; // Or, if no differing fields are required let provider = FakeProvider::default();

Rolv-Apneseth · 2026-07-15T20:07:44Z

+            .send::<String>()
+            .context("failed to query IMDS for adminUsername")?;
+
+        match username {


Suggested change

match username {

match username.map(|u| u.trim().to_owned()) {

Some(u) if !u.is_empty() => Ok(Some(u)),

_ => Ok(None),

}

Rolv-Apneseth · 2026-07-15T20:07:56Z

@@ -0,0 +1,334 @@
+// Copyright 2017 CoreOS, Inc.


Suggested change

// Copyright 2017 CoreOS, Inc.

// Copyright 2026 CoreOS, Inc.

Rolv-Apneseth · 2026-07-15T20:08:04Z

+            storage: Some(Storage {
+                files: vec![StorageFile {
+                    path: "/etc/hostname".into(),
+                    mode: 420,


I think this is clearer in octal:

Suggested change

mode: 420,

mode: 0o644,

Rolv-Apneseth · 2026-07-15T20:08:19Z

+        }
+        let json =
+            serde_json::to_string_pretty(self).context("failed to serialize ignition config")?;
+        fs::write(path, json.as_bytes())


Would it be worth writing to a temp file and renaming after the permissions are set to keep this atomic in case of a failure / crash?

Rolv-Apneseth · 2026-07-15T20:08:27Z

+            storage: Some(Storage {
+                files: vec![StorageFile {
+                    path: "/etc/hostname".into(),
+                    mode: 420,


Suggested change

mode: 420,

mode: 0o644,

gemini-code-assist Bot reviewed Mar 19, 2026

View reviewed changes

Comment thread dracut/30afterburn/module-setup.sh

Comment thread src/providers/microsoft/azure/mod.rs Outdated

peytonr18 force-pushed the probertson-generate-ignition-config branch from 6af9c2e to 50a81df Compare March 19, 2026 19:04

prestist self-requested a review March 20, 2026 19:16

prestist reviewed Mar 23, 2026

View reviewed changes

Comment thread src/cli/render_ignition.rs

Comment thread src/providers/microsoft/azure/config.rs Outdated

Comment thread src/providers/microsoft/azure/config.rs Outdated

Comment thread src/providers/microsoft/azure/config.rs Outdated

anhvoms suggested changes Mar 30, 2026

View reviewed changes

Comment thread src/providers/microsoft/azure/config.rs Outdated

dustymabe reviewed Mar 31, 2026

View reviewed changes

Comment thread dracut/30afterburn/afterburn-ignition-fragment.service Outdated

prestist mentioned this pull request Mar 31, 2026

[RFC]: Proposal for Expanding Ignition with Cloud-Specific Configuration coreos/ignition#2189

Open

prestist mentioned this pull request Apr 13, 2026

New release for afterburn 5.11.0 #1269

Open

45 tasks

peytonr18 force-pushed the probertson-generate-ignition-config branch 2 times, most recently from b2da779 to af9bd12 Compare May 4, 2026 22:42

cjp256 reviewed May 5, 2026

View reviewed changes

Comment thread src/providers/microsoft/azure/config.rs Outdated

cjp256 reviewed May 5, 2026

View reviewed changes

Comment thread src/providers/microsoft/azure/config.rs Outdated

peytonr18 force-pushed the probertson-generate-ignition-config branch from 9d71b9b to aef7dca Compare May 11, 2026 18:24

prestist reviewed May 11, 2026

View reviewed changes

Comment thread src/providers/microsoft/azure/config.rs Outdated

Comment thread src/providers/microsoft/azure/config.rs Outdated

Comment thread Cargo.lock Outdated

travier reviewed May 13, 2026

View reviewed changes

Comment thread Cargo.toml Outdated

peytonr18 force-pushed the probertson-generate-ignition-config branch from 3786e89 to c555f66 Compare May 18, 2026 21:41

prestist previously requested changes May 29, 2026

View reviewed changes

Comment thread Cargo.lock Outdated

prestist reviewed Jun 8, 2026

View reviewed changes

cjp256 reviewed Jun 9, 2026

View reviewed changes

Comment thread dracut/30afterburn/afterburn-ignition-fragment.service Outdated

peytonr18 force-pushed the probertson-generate-ignition-config branch from d2bb19f to 9d6be5c Compare June 17, 2026 16:12

cjp256 reviewed Jun 18, 2026

View reviewed changes

Comment thread dracut/30afterburn/module-setup.sh Outdated

cjp256 reviewed Jun 18, 2026

View reviewed changes

Comment thread dracut/30afterburn/afterburn-ignition-fragment.service

prestist approved these changes Jun 26, 2026

View reviewed changes

peytonr18 added 2 commits June 29, 2026 17:10

azure: Add render-ignition subcommand for Ignition fragments

54a726c

dracut: Add afterburn-ignition-fragment.service

68762e9

peytonr18 force-pushed the probertson-generate-ignition-config branch from e40335b to 68762e9 Compare June 30, 2026 00:10

cjp256 reviewed Jun 30, 2026

View reviewed changes

Comment thread src/providers/microsoft/azure/config.rs Outdated

cjp256 reviewed Jul 6, 2026

View reviewed changes

Comment thread src/cli/render_ignition.rs Outdated

cjp256 reviewed Jul 6, 2026

View reviewed changes

peytonr18 added 2 commits July 7, 2026 10:46

Rolv-Apneseth reviewed Jul 15, 2026

View reviewed changes

	slog_scope::warn!("render-ignition: all fragments disabled, nothing to do");
	warn!("render-ignition: all fragments disabled, nothing to do");

-    let hostname = match provider.hostname()? {
+    let Some(hostname) = provider.hostname()? else {
+        warn!("hostname requested, but not available from this provider");
+        return Ok(());
+    };

+    if ssh_keys.is_empty() && password_hash.is_none() {
+        warn!("admin username present but no SSH keys or password; skipping user fragment");
+        return Ok(());
+    }

-        match username {
+        match username.map(|u| u.trim().to_owned()) {
+            Some(u) if !u.is_empty() => Ok(Some(u)),
+            _ => Ok(None),
+        }

	// Copyright 2017 CoreOS, Inc.
	// Copyright 2026 CoreOS, Inc.

Uh oh!

Conversation

peytonr18 commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

New render-ignition subcommand

Azure fragment generation (src/providers/microsoft/azure/config.rs)

OVF / IMDS source rules

Systemd / Dracut integration

CLI usage

Existing functionality is untouched

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

prestist commented Mar 23, 2026

Uh oh!

prestist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

peytonr18 commented Mar 24, 2026

Uh oh!

prestist commented Mar 25, 2026

Uh oh!

prestist commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

prestist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

prestist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

prestist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

prestist left a comment

Choose a reason for hiding this comment

Uh oh!

peytonr18 commented Jun 30, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peytonr18 Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prestist commented Jul 15, 2026

Uh oh!

Rolv-Apneseth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

peytonr18 commented Mar 19, 2026 •

edited

Loading

New `render-ignition` subcommand

Azure fragment generation (`src/providers/microsoft/azure/config.rs`)

peytonr18 Jul 7, 2026 •

edited

Loading