Fedora CoreOS Group Weekly Meeting

# Fedora CoreOS Group Weekly Meeting ## Summary Steven Presti and Peyton Robertson initiated a discussion on expanding Ignition with a cloud-specific configuration for Azure to enhance its provisioning capabilities and support future features like confidential VMs. Chris Patterson compared provisioning agents, noting that Azureinit is a minimal replacement for the provisioning component of the WA Linux agent, and discussed extending Ignition to handle configuration fetching and merging for optimal performance, while emphasizing that future features like confidential VMs require changes in how Ignition retrieves potentially encrypted custom data. Dusty Mabe proposed an architecture where Afterburn generates an Ignition configuration from the metadata service to maintain separation of concerns, an approach that Timothée Ravier was concerned would fundamentally change Ignition's design philosophy by adding platform-specific logic and potentially injecting configurations without explicit user provision, despite Peyton Robertson acknowledging this opposition to the existing design. Steven Presti suggested that any new feature should be implemented as a general interface in Ignition for other providers to use, and Peyton Robertson committed to providing clarity on confidential computing plans to inform the decision between fully merging Afterburn into Ignition or having Afterburn generate configs for merging, with Joe Doss joining late and confirming the topic of discussion. ## Details - Expanding Ignition with Azure Configuration Steven Presti opened the meeting to discuss expanding Ignition with a cloud-specific configuration for Azure. Peyton Robertson explained that the proposal aims to remove the WA Linux agent from Flatcar and align Ignition more closely with how cloud-init works to make it a first-class provisioning agent on Azure. This is intended to support future changes, particularly with confidential VMs and AKS (00:00:00). - Comparison of Provisioning Agents Chris Patterson noted that Azureinit is designed as a minimal provisioning agent, serving as a potential drop-in replacement for the WA Linux agent's provisioning aspects. However, there is some overlap between what Ignition needs from provisioning media and what Azureinit does, meaning Azureinit is not a full replacement (00:01:31) (00:04:17). The WA Linux agent has two components: a guest agent for extensions (which remains) and a provisioning component (which Azureinit is meant to replace to offload maintenance from the guest agent team) (00:04:17). - Extending Ignition for Azure Chris Patterson discussed the option of extending Ignition to mimic the treatment of the cloud-init local service today. This would involve fetching the required configuration, mapping it to cloud configuration, merging it with user-provided configurations, and handling updates such as setting the Azure admin user, password, and SSHD configurations (00:02:49). Doing this in Ignition early in the boot process is considered optimal for performance, getting all operations done at once (00:08:43). - Future Features and Dependencies Chris Patterson mentioned that future features, like confidential VMs, will require changes in how Ignition retrieves custom data and user data, potentially involving encrypted or signed data that needs validation (00:02:49) (00:11:40). Other upcoming features include the metadata security protocol (MSP) for encryption and validation of calls to IMDS and wire server (00:10:03), and pre-provisioning services (PPS) to reduce latency (00:11:40). - Afterburn's Role and Limitations Steven Presti and Dusty Mabe inquired about the suitability of Afterburn, suggesting that its late execution in the process is a problem for initial provisioning and dealing with encrypted metadata (00:13:05). Chris Patterson confirmed that Afterburn lacks the facilities to perform critical operations already handled by Ignition, such as creating a user. Expanding Afterburn to include this functionality would effectively be reimplementing Azureinit, making it less logical than extending Ignition to handle these constrained sets of operations (00:07:24) (00:14:15). - Proposal for Afterburn as an Ignition Config Generator Dusty Mabe proposed an architecture where Afterburn remains the sole component that reads the metadata service, interpreting it to generate an Ignition configuration. This generated config would then be stashed for Ignition to pick up and merge with the user-provided config, thereby maintaining separation of concerns: Ignition focuses on user data, and Afterburn on metadata service interpretation (00:19:47) (00:22:33). Dusty Mabe suggested that if this approach is adopted for Azure, it should be applied to all platforms where Afterburn is used (e.g., for hostnames) (00:34:14). - Merging Logic and Conflict Resolution Timothée Ravier and Chris Patterson discussed the complexities of merging configurations, especially since Ignition would need to support processing multiple configs or handle the merging itself (00:24:02). Timothée Ravier raised concerns about the priority of conflicting settings, such as hostnames, and noted that Ignition currently has no mechanism to "reset" configuration (00:28:08) (00:30:34). Dusty Mabe suggested that user data should win over metadata service settings in case of conflicts (00:29:17). - Impact on Ignition Design Philosophy Timothée Ravier expressed concern that adding cloud-specific extensions or logic to Ignition would fundamentally change its design, which is currently focused on providing the same system regardless of the cloud platform. They noted that this approach could introduce branching logic based on the platform state, potentially injecting configurations without the user's explicit provision (00:38:20). Peyton Robertson acknowledged that this approach introduces cloud-specific functionality that might be in opposition to the existing design (00:39:53). - Next Steps and Clarification on Future Goals Dusty Mabe emphasized the need to determine the best long-term architecture and suggested two options: fully merging Afterburn into Ignition, or having Afterburn generate Ignition configs for merging (00:50:55). Both Steven Presti and Timothée Ravier requested more clarity on the confidential computing and PPS plans to ensure that any current design decisions do not negatively impact future goals (00:45:49) (00:51:55). Peyton Robertson committed to fleshing out the confidential computing situation and sharing this information to inform the decision-making process (00:47:19). - Afterburn and Ignition Integration Timothée Ravier committed to commenting on the ticket regarding metadata. Dusty Mabe explained that Afterburn's task is to read metadata, interpret it into an Ignition config snippet, and store it on the file system for Ignition to process. They also noted that dealing with multiple metadata sources complicates Afterburn's process (00:59:56). - Generalizing Cloud-Specific Features Steven Presti suggested that any new feature related to cloud booting, even if prompted by an Azure concern, should be designed as a general interface in Ignition that is added by the metadata service, allowing other providers to use it as well. Dusty Mabe agreed that the feature should not be Azure-specific and should be a plug-in where Ignition looks for and processes cloud-provided configurations (01:01:12). - Next Steps and Design Consideration for Option Two Peyton Robertson confirmed that their team had internally tested a similar proposal and would follow up with answers regarding confidential computing plans and more detailed thoughts on pursuing "option two". Dusty Mabe emphasized the need for further design discussions, even with option two, concerning where Ignition should merge files, its behavior, and whether to include a user-facing knob to disable the feature (01:02:36). They also noted that if they proceed with option two, they still need to define the interface between the two interacting components and assign responsibilities (01:03:56). - Communication and Follow-up Meetings Peyton Robertson mentioned that their team successfully rewrote Afterburn in Rust and prefers working with Rust over Go. Both Dusty Mabe and Peyton Robertson agreed that video meetings are more effective for discussing complex topics like design (01:03:56). Peyton Robertson confirmed they would message the Matrix channel to schedule a follow-up meeting, as the conversation about this topic has been ongoing since at least October. Joe Doss joined late and confirmed with Timothée Ravier that the discussion revolved around a cloud-specific extension for Ignition (01:04:58). ## Next steps - Peyton plans to investigate confidential computing implementation options and review the proposal and check Afterburn metadata. Then in 3 or so weeks is planing to request a follow-up video meeting via Matrix to discuss design and complex topics.