Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2236858 ** Information from BlockerBugs App:
Commented but haven't voted yet: kparal, pbrobinson, mhayden
The votes have been last counted at 2023-09-04 15:50 UTC and the last processed comment was #comment-872635
To learn how to vote, see: https://pagure.io/fedora-qa/blocker-review A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
+1 BetaFE
I'm not sure about this one. It seems it's only needed for some experimental stuff Cloud SIG is doing. I don't feel good about changing things during a freeze just to aid work on something that has nothing to do with the Beta release.
I do have the same impression as Adam from the bugzilla ticket. @mhayden Can you please elaborate why it is necessary for the update to break the freeze and what exactly it fixes?
You can't configure some cloud instances with usernames or ssh keys without cloud-init, it's not used or triggered elsewhere so it's low risk for the distro as a whole so from me: +1
When you create an image for a cloud deployment (could be public clouds, VMWare, VirtualBox, OpenStack, etc), you normally install cloud-init there to handle the configuration on the first boot. Cloud-init reads all of that metadata from the services that the cloud provides and ensures that network devices are configured, ssh keys are deployed, and new users are created.
If you build a cloud image and install cloud-init without remembering to enable the services, then your system boots up, cloud-init never starts, and your instance remains unconfigured. In most cases, this means you don't have working network adapters and your ssh keys are missing.
This change always ensures that if you installed cloud-init for a cloud deployment, then cloud-init will be set to start at first boot. We ran into this problem when we build a Fedora image for Azure using osbuild and cloud-init did not start on the first boot. The same issue can crop up on other clouds, too.
If cloud-init runs a second time on a cloud system that was already provisioned, cloud-init notices that the remnants of its last run are still on the system and it won't make any changes.
Other Fedora editions, such as Server or Workstation, do not have cloud-init installed and they won't see any changes from these presets.
well, okay, I guess. BetaFE +1 AGREED AcceptedBetaFE
The following votes have been closed:
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F39 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.