Bug 2203192 - Fedora Images on Azure
Summary: Fedora Images on Azure
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 39
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Neal Gompa
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: F39Changes
TreeView+ depends on / blocked
 
Reported: 2023-05-11 13:35 UTC by Ben Cotton
Modified: 2024-02-05 22:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-14 18:54:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ben Cotton 2023-05-11 13:35:51 UTC
This is a tracking bug for Change: Fedora Images on Azure
For more details, see: https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure

Azure is a massive public cloud and offering an official Fedora Cloud image there would expand Fedora's user base. It also gives Fedora Cloud users more options when selecting public clouds.

If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.

Comment 1 Major Hayden 🤠 2023-05-16 14:39:23 UTC
Images are rolling out now: https://koji.fedoraproject.org/koji/buildinfo?buildID=2201154

However, they are dynamic VHDs and not fixed VHDs. I used these commands to fix the image and upload it:

qemu-img convert -f vpc -O raw Fedora-Cloud-Base-Azure-Rawhide-20230516.n.0.x86_64.vhd Fedora-Cloud-Base-Azure-Rawhide-20230516.n.0.x86_64.raw
qemu-img convert -f raw -O vpc -o subformat=fixed,force_size Fedora-Cloud-Base-Azure-Rawhide-20230516.n.0.x86_64.raw Fedora-Cloud-Base-Azure-Rawhide-20230516-fixed.n.0.x86_64.vhd

However, there's a new error about the size:

The VHD for disk 'Fedora-Cloud-Base-Azure-Rawhide-20230516-fixed.n.0.x86_64.vhd' with blob Fedora-Cloud-Base-Azure-Rawhide-20230516-fixed.n.0.x86_64.vhd has an unsupported virtual size of 5120.2265625 MB. The size must be a whole number in (MBs)."

Comment 2 Major Hayden 🤠 2023-05-16 14:50:22 UTC
Ah here's the right path from Azure's docs:

  https://learn.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-generic#resizing-vhds

Comment 3 Major Hayden 🤠 2023-05-16 21:50:43 UTC
Opened an upstream issue with imagefactory to figure out how we can get the code updated:

  https://github.com/redhat-imaging/imagefactory/issues/453

The existing HyperV code seems to do about 1/3 of what we need. I'm not sure if we need a new piece of code for Azure or if we can add to what's already there for HyperV.

Comment 4 Adam Williamson 2023-08-22 22:23:39 UTC
Can we get a status update here, please? We're past the Beta freeze, which means all Changes are supposed to be "100% code complete" at this point. Is that where we are with this? I see the change in pungi-fedora was made, but not sure what else needs doing. Thanks.

If the change is 100% complete, set the status to ON_QA. If it's at least "testable", set it to MODIFIED.

Comment 5 Neal Gompa 2023-08-23 13:44:53 UTC
(In reply to Major Hayden 🤠 from comment #3)
> Opened an upstream issue with imagefactory to figure out how we can get the
> code updated:
> 
>   https://github.com/redhat-imaging/imagefactory/issues/453
> 
> The existing HyperV code seems to do about 1/3 of what we need. I'm not sure
> if we need a new piece of code for Azure or if we can add to what's already
> there for HyperV.

QEMU will be able to take a HyperV VHDX and properly convert it to an Azure VHD just fine.

The following command will do the trick:

$ qemu-img convert -p -f vhdx -O vpc -o subformat=fixed,force_size image.vhdx image.vhd

Comment 6 Major Hayden 🤠 2023-08-23 13:51:07 UTC
Right, I mentioned that above in the BZ, but then Azure requires an exact size to be set that is in a whole number of MBs.

Comment 7 Adam Williamson 2023-08-23 16:29:33 UTC
If we have a roadblock here which can't be solved really very soon indeed, this is probably gonna need to be deferred to F40, I think...

Comment 8 Major Hayden 🤠 2023-08-23 19:12:19 UTC
Agreed, Adam.

In other news, the delightful Peter Robinson and Ondřej Budai helped me figure out how to get koji building scratch Azure images:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=105188156

I uploaded that to Azure and it boots just fine on x86_64 instances. 🎉

We're still coming up short in a few areas:

1) Automating the upload from Fedora infra to Azure
2) Getting a btrfs filesystem by default
3) cloud-init needs to start up on first boot
4) We need to test Arm images, too

Ondřej has a PR upstream for #3, and #2 has the work defined but nobody is available to work on it. I'm hoping that #4 is fairly straightforward by specifying the architecture to koji for a scratch build.

#1 will take some more work with David Duncan and Brian Stinson to figure out credentials and signing.

Comment 9 Peter Robinson 2023-08-23 21:48:22 UTC
> available to work on it. I'm hoping that #4 is fairly straightforward by
> specifying the architecture to koji for a scratch build.

It should be just doing so in the pungi build or for a scratch adding --arch-override=aarch64 to the command options.

Comment 10 Adam Williamson 2023-09-15 06:30:37 UTC
Where are we with this for Beta? Are we going to have a Beta image available in Azure?

Comment 11 Adam Williamson 2023-09-15 06:30:49 UTC
If not, we should probably defer this.

Comment 12 Aoife Moloney 2023-11-14 18:54:08 UTC
F39 was released on November 7th, so I am closing this tracker. If this Change was not completed, please notify me ASAP.

Comment 13 Aoife Moloney 2023-11-14 18:57:27 UTC
F39 was released on November 7th, so I am closing this tracker. If this Change was not completed, please notify me ASAP.

Comment 14 Akira Yamamoto 2024-01-18 23:39:21 UTC
Hi. Are there any plans to publish the Fedora images to the Azure Marketplace?

Comment 15 Adam Williamson 2024-01-19 00:42:36 UTC
that's a q for Major or davdunc, not Aoife...

Comment 16 Major Hayden 🤠 2024-02-05 22:19:38 UTC
I think Neal is working on this now with David Duncan.


Note You need to log in before you can comment on or make changes to this bug.