UI decisions based on payload

[Colin Walters]

I wanted to start a quick architecture discussion here based on
https://github.com/projectatomic/fedora-productimg-atomic/pull/3

I'd like down the line if more decisions like this were based on
the *content* and not the productimg, because it's more generic.
It'd be quite possible and reasonable for someone to regenerate
the ostree commit with documentation downstream.

Similarly, people composing Workstation systems are probably
going to include docs.

In a network install scenario, I know this gets a bit more complex,
as we would need to fetch some metadata (which could be the ostree
commit object) to determine this.

But in the case of an Atomic Host ISO where we embed
the ostree content, there shouldn't be any network bootstrapping issues;
we have the content in the ISO. That way things would similarly
Just Work for a Workstation case

In order to make this work, we'd need to teach rpm-ostree
to write out well-known metadata in the ostree commit, and
change Anaconda to look for it.

[Martin Kolman]

Post by Colin Walters
I wanted to start a quick architecture discussion here based on
https://github.com/projectatomic/fedora-productimg-atomic/pull/3
I'd like down the line if more decisions like this were based on
the *content* and not the productimg, because it's more generic.
It'd be quite possible and reasonable for someone to regenerate
the ostree commit with documentation downstream.
Similarly, people composing Workstation systems are probably
going to include docs.
In a network install scenario, I know this gets a bit more complex,
as we would need to fetch some metadata (which could be the ostree
commit object) to determine this.

Yep - at least in the case of the single language mode you basically
need to decide before the GUI shows up as you are disabling parts of
it. 

If for example the user needs to manually setup the network and
installation source first its kinda to late to retroactively disable
the language configuration spokes that have already been shown to the
user and that might have been interacted with.

Well, *theoretically* it could work in reverse - you start in single
language mode but turn it off once you can read the metadata from the
network. But that would still mean you could not change the
installation language, just the installed system language & there might
be some issues with this as we currently don't change spoke visibility
once a hub has been loaded.

Post by Colin Walters
But in the case of an Atomic Host ISO where we embed
the ostree content, there shouldn't be any network bootstrapping issues;
we have the content in the ISO.  That way things would similarly
Just Work for a Workstation case

The single-language mode can also be triggered with the inst.singlelang
boot option - so I guess if you know you want to run the installation
in single language mode when you create a media you could make sure
that boot option is used when booting from it.

Post by Colin Walters
In order to make this work, we'd need to teach rpm-ostree
to write out well-known metadata in the ostree commit, and
change Anaconda to look for it.
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list