PR#381: AH: Stop generating raw-xz images - pungi-fedora

pungi-fedora

#381 AH: Stop generating raw-xz images

Closed 5 years ago by kevin. Opened 6 years ago by walters.

walters/pungi-fedora atomic-no-raw-xz into master

Colin Walters • 6 years ago

354ba66

fedora-atomic.conf

file modified

+1 -1

		`@@ -217,7 +217,7 @@`
		`'^CloudImages$': [`
		`{`
		`'image-build': {`
		`- 'format': [('qcow2','qcow2'), ('raw-xz','raw.xz')]`
		`+ 'format': [('qcow2','qcow2')]`
		`'name': 'Fedora-Atomic',`
		`'target': 'f26',`
		`'version': '26',`

fedora.conf

file modified

+1 -1

		`@@ -348,7 +348,7 @@`
		`},`
		`{`
		`'image-build': {`
		`- 'format': [('qcow2','qcow2'), ('raw-xz','raw.xz')],`
		`+ 'format': [('qcow2','qcow2')],`
		`'name': 'Fedora-Atomic',`
		`'kickstart': 'fedora-atomic.ks',`
		`'distro': 'Fedora-22',`

walters commented 6 years ago

I have no idea why we're shipping these. No one should use them;
it's equivalent data to the qcow2 which is a more flexible format;
it's spoken natively by OpenStack, etc.

For example, libguestfs has a lot of capability to access qcow2 files if you
need that.

Just doing this PR as I noticed it showing up as missing in
compose checker.

I didn't touch "Cloud Base" intentionally, but I obviously would
have no objections if someone did the same there.

Signed-off-by: Colin Walters walters@verbum.org

ausil commented 6 years ago

nak, we upload the raw.xz to AWS

ausil commented 6 years ago

fedimg does a wget of the raw.xz and xzcat's it to the raw block device and then registers it as a AMI

walters commented 6 years ago

Oh, yuck. Hmm, OK: https://github.com/fedora-infra/fedimg/issues/64

ausil commented 6 years ago

@rjones some of your tooling relies on the raw.xz or raw image right?

dustymabe commented 6 years ago

yeah probably, and a lot of people take the raw image and convert it to other formats. probably safer just to keep shipping it at this point.

is it causing problems?

rjones commented 6 years ago

We don't use the Fedora raw.xz images.

I'm in two minds about the change proposed however. On the one hand you can convert a .qcow2 file to raw with a single qemu-img convert command. On the other hand reliable qcow2 handling needs qemu/KVM tooling and the raw images will work directly on other hypervisors (Amazon has been mentioned, but also VMware, Hyper-V etc do not support qcow2).

pbrobinson commented 6 years ago

It's also useful in other usecases (I've used cloud images on ARM SBCs directly in the past)

mattdm commented 6 years ago

Historical note: it's there originally for Eucalyptus, which didn't support qcow.

kevin commented 5 years ago

I guess there's still uses for these (although I personally wouldn't mind dropping them to save compose time/space/cpus).

So, closing this for now... if someone wants to push to remove them, perhaps they could file a change and get general agreement that it's ok to drop them?