user-guide/00-introduction: Describe image builder output formats

[schuellerf]

Add short hint on the difference between
image-installer and live-installer.

[schuellerf]

Please give me some hints if I got it right. Is there some better / more detailed documentation about those types somewhere?

[ht-vo]

Hi @schuellerf, to keep it short, isn't it clearer to describe this way:

• Installer (unattended)
• Installer (interactive mode)

[schuellerf]

As far as I tested - It's not 'unattended' just more things preconfigured…

[schuellerf]

Improved wording after collecting some input what happens in the background.

[achilleas-k]

I think it's a good idea to describe image types (especially the less obvious ones) in plain language, but I don't know if the current table is good for that. The first column, Description, isn't really a description so much as it is an acronym expansion for most image types. It's a bit weird to have a 2-3 word name for all image types except these two that have a short sentence describing them. Maybe all the other ones are obvious though? I don't know.

I'd propose changing the table to have the following columns:

• Name
• CLI name
• File extension
• Description

Obvious ones can have very short descriptions:

Name	CLI name	File extension	Description
QEMU Image	qcow2	.qcow2	QCOW2 formatted disk image for use with QEMU/Libvirt
Amazon Machine Image	ami	.ami	Raw disk image for use with AWS EC2
Oracle Cloud Infrastructure Image	oci	.qcow2	QCOW2 formatted disk image for use with Oracle Cloud. This is identical to the qcow2 image.

And then the two installers can be described as

Name	CLI name	File extension	Description
Image installer	image-installer	.iso	Anaconda ISO with an embedded pre-built OS archive.
Live installer	live-installer	.iso	Anaconda ISO with a live operating system.

Not sure those are the best descriptions for the ISOs, but we can workshop them.

[schuellerf]

I reworked the table, although this might move into the application somewhere and the table here will ideally be generated, this might be a starting point.

Please double check if I understood the functionalities of the image types correctly

[schuellerf]

@ht-vo as a hint. If the installer runs unattended or not, depends on the configuration. If all values are present for anaconda to continue it will be unattended otherwise it will ask. If "all necessary values" are configured is virtually impossible to check beforehand, anaconda decides…
…Hmm I should add a sentence like this to the docs also :-D

[achilleas-k]

The IoT (and Edge) containers are actually little web server containers that serve an ostree commit. It's meant to make it convenient to set up a single-commit ostree repo for building an ISO or disk image.

So maybe something like:

Web server container that embeds and serves an ostree repository with a single commit.

[achilleas-k]

I think

OSTree commit archive.

is a bit more clear here. Calling it an image might imply it's a disk image, which it isn't. It's just a bare ostree commit tarball (which is actually an ostree repo with a single commit, but that's a bit too much of a detail).

[schuellerf]

I hope the description is better now
also for *-simplified-installer is that correct "… using FIDO or ignition."?

[achilleas-k]

Thanks. LGTM