Re: Notifying post-install tools about screens seen by the user

----- Original Message -----
> From: "Rob Marshall" <[email protected]>
> To: "Discussion of Development and Customization of the Red Hat Linux Installer" <[email protected]>
> Cc: "Martin Kolman" <[email protected]>, "David Cantrell" <[email protected]>
> Sent: Wednesday, November 11, 2015 6:09:48 PM
> Subject: Re: Notifying post-install tools about screens seen by the user
> 
> This is a great idea and I'd like to contribute the following thoughts based
> on the discussion up to this point.
> 
> > From: "Martin Kolman" <[email protected]>
> > To: [email protected]
> > Sent: Thursday, November 5, 2015 10:59:07 AM
> > Subject: Notifying post-install tools about screens seen by the user
> > Manual installation description file proposal
> > 
> > * use the "INI file like" config file format
> > - can be easily parsed from Python using the configparser module
> > - should be also easy to parse from C and other programming languages
> >   due to widespread use of INI files
> > * stored in /etc/anaconda/manual_installation.ini
> 
> The /etc directory is for running system configuration per the FHS and,
> although a user is choosing configuration information, it is stored
> elsewhere on the system and is no longer apropos after installation and
> first boot processes are completed.
> 
> For these reasons I would recommend using Pat Riehecky's suggestion of
> sticking with Anaconda Class Names and putting the files here:
>     /var/log/anaconda/interactive/{ClassName}.conf
Still, putting configuration files possibly edited by multiple tools to /var/log seems weirder than
putting configuration files that might not be used ever again to /etc/anaconda.

Also I don't think it is a good idea to have more than one configuration file for this
due to increased parsing & writing complexity. 

It would also make it more difficult to check the state manually due to having to check multiple files vs just checking one.

> 
> 
> > From: "David Cantrell" <[email protected]>
> > To: "Discussion of Development and Customization of the Red Hat Linux
> > Installer" <[email protected]>
> > Sent: Friday, November 6, 2015 4:41:07 AM
> > Subject: Re: Notifying post-install tools about screens seen by the user
> > The downside to that is that we'd start overloading kickstart with UX
> > metadata, which seems unnecessary.  That and the parser for it is Python
> > only, which would make it difficult for programs like g-i-s.  I think we
> > can
> > probably do this with VARIABLE=VALUE syntax
> 
> I agree with David that the file should have a syntax VARIABLE=VALUE rather
> than the INI syntax. The variable's scope is handled by the aforementioned
> ClassName.conf convention.
The idea is to use the VARIABLE=VALUE syntax (which is what INI files use)
and use the section headers for scope to have everything in a single file.

> 
> It makes sense to note that a user visited a spoke and I agree with the folks
> who have made the case to note whether something was explictly chosen. Using
> the established Time Zone example and assuming Boston is default:
> 
>   TZ=US/BOSTON
>   TZ_DEFAULT=1
> 
>   TZ=US/NEW YORK
>   TZ_DEFAULT=0
This is a bit more complicated - while there is a default (US/New York I think ?)
there are multiple ways of setting a timezone without visiting the timezone spoke:
* successful geolocation lookup sets timezone
* timezone can be set through kickstart

So we can have a non-default timezone even if the user just visited the spoke a then
exited it without changing anything.

Therefore I think it rather makes sense to record that a user:
* visited a spoke at all (ad supposedly saw what's on the screen)
* if the user changed something
- for the timezone spoke example, just noting changes in timezone, time+date and ntp config should be enough
- this could be done in quite a simple way in Anaconda via a decorator around something that's called when user sets the value

As for recording *what* the user selected - I'm not sure that's a good idea, at least for the initial implementation. It would mean at least partially duplicating what kickstart does and makes the stable "API" quite a bit more complex and possibly harder to maintain
in the future.

> 
> The explicit benefit here is decoupling consumers of the file from a forced
> knowledge of Anaconda defaults should they change in the future.
> 
> --Rob
>