Notifying post-install tools about screens seen by the user

[Martin Kolman]

The idea is that we should not show configuration screens the users has
already visited during the installation in post-installation tools,
such as Initial Setup and Gnome Initial Setup.

An example of such a screen is the timezone spoke - if the user already
visited the timezone spoke during the installation it is unlikely to be
useful showing it again in IS or GIS. So there should be a way for
Anaconda to tell the post-installation tools what screens have been
visited by a user during the installation, so that the tools can hide
or skip the given screen.

While Anaconda already produces a kickstart file after successful
installation, the resulting commands in the file don't really map to
individual screens and there is no information about what commands have
been generated automatically, based on user action or which were part
of an initial kickstart file used for the installation. Also parsing a
kickstart file in a robust way really requires Pykickstart, which might
not be straightforward to use (at least without wrappers) from post
-install utilities not written in Python, such as Gnome Initial Setup.

Therefore a separate simple configuration file forwarding the needed
information about visited screens to post-installation tools is needed.


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
- other name/path suggestions welcome! :)
* header sections corresponding to spokes
* sections for now only contain a visited=1 key/value pair
* could be easily extended in the future to include more information
about what user did in the spoke if needed
* example config file snippet:

[DatetimeSpoke]
visited=1

* it seems sensible to write sections only for spokes that the user
visited, not all spokes
* all sub-classes of the Spoke class should be recorder if they are
visited, including addons
* Initial Setup will also need to record spoke visits as there might be
another setup tool chained behind it
(and GIS indeed runs after IS on RHEL7)
* should we also report hubs the user has visited ? at least for now

the number of hubs and their order are fixed

Looking forward to your feedback! :)

[Pat Riehecky]

Post by Martin Kolman
* stored in /etc/anaconda/manual_installation.ini
- other name/path suggestions welcome!:)

Perhaps: /etc/anaconda/human_interaction.ini ?

[Martin Kolman]

Post by Pat Riehecky

Post by Martin Kolman
* stored in /etc/anaconda/manual_installation.ini
- other name/path suggestions welcome!:)

Perhaps: /etc/anaconda/human_interaction.ini ?

I like it! human_interaction.ini sounds definitely better than the
original name.

[Brian C. Lane]

Post by Martin Kolman
Looking forward to your feedback! :)

Some random thoughts:

Ideally we wouldn't have to do this. The other apps should be able to
detect when something has been changed from the default and skip it.

Synchronizing this configuration file between anaconda and the other
apps means that any changes we make will need to be coordinated.

Will the entries in the file be translated? I'd suggest they be in
English.

/etc/sysconfig/anaconda or /etc/default/anaconda seems like a better
place for this than a whole new directory in /etc/

Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

I almost like the idea of parsing the kickstart better, it is already a
known well defined format, we already write it out, and it wouldn't
require coordinating a new thing with everyone.

[David Cantrell]

Post by Brian C. Lane

Post by Martin Kolman
Looking forward to your feedback! :)

Ideally we wouldn't have to do this. The other apps should be able to
detect when something has been changed from the default and skip it.

The goal should be to skip the screen if the user previously visited a
similar or the same screen. But visiting a screen doesn't mean they made a
change. All of those UX aspects aren't really recorded in setting the
timezone for the system. I agree that other apps should skip it if the
default has been changed, but we don't record the default anywhere. Maybe
that's how we record the state change.

Post by Brian C. Lane
Synchronizing this configuration file between anaconda and the other
apps means that any changes we make will need to be coordinated.

True, this would now be a public API. But that's not necessarily a bad
thing.

Post by Brian C. Lane
Will the entries in the file be translated? I'd suggest they be in
English.

I don't think translation is important here since it's a config file that
users don't ever have to look at.

Post by Brian C. Lane
/etc/sysconfig/anaconda or /etc/default/anaconda seems like a better
place for this than a whole new directory in /etc/

I like either of these ideas. That file could also carry more UX
information if we need to in the future.

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

I think so.

Post by Brian C. Lane
I almost like the idea of parsing the kickstart better, it is already a
known well defined format, we already write it out, and it wouldn't
require coordinating a new thing with everyone.

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 in a /etc/sysconfig/anaconda
file.

[Martin Kolman]

Post by David Cantrell

Post by Brian C. Lane

Post by Martin Kolman
Looking forward to your feedback! :)

Ideally we wouldn't have to do this. The other apps should be able to
detect when something has been changed from the default and skip it.

The goal should be to skip the screen if the user previously visited a
similar or the same screen. But visiting a screen doesn't mean they made a
change. All of those UX aspects aren't really recorded in setting the
timezone for the system. I agree that other apps should skip it if the
default has been changed, but we don't record the default anywhere.
Maybe
that's how we record the state change.

Post by Brian C. Lane
Synchronizing this configuration file between anaconda and the other
apps means that any changes we make will need to be coordinated.

True, this would now be a public API. But that's not necessarily a bad
thing.

I think as long as there is a definitive spec somewhere (say in the
Anaconda source tree) and any backward incompatible changes are
communicated to all known users it should be fine.

On a related note - what about the screen/spoke naming ?
The original idea was just to use the Anaconda spoke class names,
but maybe some generic naming should be used ?

Say KeyboardScreen instead of KeyboardSpoke ?

Also what about "combined" screens ? For example the TimedateSpoke has
both timezone and time+date configuration - so what's actually the
correct thing to write to the config file ?

[TimedateScreen]
visited=1

or rather

[TimezoneScreen]
visited=1

[TimedateScreen]
visited=1

?

The second option would handle the possibility that different tools
might have different "batching" of settings on individual screens, for
example:

Tool A having just a timezone screen, this marks TimedateScreen as
visited.
Tool B has a combined timezone and time+date configuration screen, but
it is skipped due to the TimedateScreen appearing as visited, this
making it impossible for user to set a the time & date.

Post by David Cantrell

Post by Brian C. Lane
Will the entries in the file be translated? I'd suggest they be in
English.

I don't think translation is important here since it's a config file that
users don't ever have to look at.

Yes, it should contain only machine readable information in English, so
no translations are needed.

Post by David Cantrell
/etc/sysconfig/anaconda or /etc/default/anaconda seems like a better

Post by Brian C. Lane
place for this than a whole new directory in /etc/

I like either of these ideas. That file could also carry more UX
information if we need to in the future.

Yeah, both also sound good to me + we are not the only software project
called "anaconda", so this might as an added benefit help avoid
collisions.

Maybe one additional issue - should the folder be called "anaconda" or
maybe as something neutral, such as "installation" or os_installation"
? I'm asking because according to Michaels email, it might happen that
some tools would be writing to the file even before Anaconda is
started.

On the other hand the "spec" should be managed as part of the Anaconda
project, so naming the folder containing the config accordingly also
makes sense.

Post by David Cantrell

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

I think so.

Post by Brian C. Lane
I almost like the idea of parsing the kickstart better, it is already a
known well defined format, we already write it out, and it wouldn't
require coordinating a new thing with everyone.

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 in a
/etc/sysconfig/anaconda
file.

[Pat Riehecky]

Post by Martin Kolman

Post by David Cantrell

Post by Brian C. Lane

Post by Martin Kolman
Looking forward to your feedback! :)

Ideally we wouldn't have to do this. The other apps should be able to
detect when something has been changed from the default and skip it.

The goal should be to skip the screen if the user previously visited a
similar or the same screen. But visiting a screen doesn't mean they made a
change. All of those UX aspects aren't really recorded in setting the
timezone for the system. I agree that other apps should skip it if the
default has been changed, but we don't record the default anywhere.
Maybe
that's how we record the state change.

Post by Brian C. Lane
Synchronizing this configuration file between anaconda and the other
apps means that any changes we make will need to be coordinated.

True, this would now be a public API. But that's not necessarily a bad
thing.

I think as long as there is a definitive spec somewhere (say in the
Anaconda source tree) and any backward incompatible changes are
communicated to all known users it should be fine.
On a related note - what about the screen/spoke naming ?
The original idea was just to use the Anaconda spoke class names,
but maybe some generic naming should be used ?
Say KeyboardScreen instead of KeyboardSpoke ?
Also what about "combined" screens ? For example the TimedateSpoke has
both timezone and time+date configuration - so what's actually the
correct thing to write to the config file ?
[TimedateScreen]
visited=1
or rather
[TimezoneScreen]
visited=1
[TimedateScreen]
visited=1
?
The second option would handle the possibility that different tools
might have different "batching" of settings on individual screens, for
Tool A having just a timezone screen, this marks TimedateScreen as
visited.
Tool B has a combined timezone and time+date configuration screen, but
it is skipped due to the TimedateScreen appearing as visited, this
making it impossible for user to set a the time & date.

If this file is to be parsed by computers, rather than people, I'd
rather stick with the Anaconda Class names. It makes it easier to see
what options/attributes/etc are located there. I think it might also
make the code cleaner for launching the class later - fewer text
substitutions to get to the actual code.

Post by Martin Kolman

Post by David Cantrell

Post by Brian C. Lane
Will the entries in the file be translated? I'd suggest they be in
English.

I don't think translation is important here since it's a config file that
users don't ever have to look at.

Yes, it should contain only machine readable information in English, so
no translations are needed.

Post by David Cantrell
/etc/sysconfig/anaconda or /etc/default/anaconda seems like a better

Post by Brian C. Lane
place for this than a whole new directory in /etc/

I like either of these ideas. That file could also carry more UX
information if we need to in the future.

Yeah, both also sound good to me + we are not the only software project
called "anaconda", so this might as an added benefit help avoid
collisions.
Maybe one additional issue - should the folder be called "anaconda" or
maybe as something neutral, such as "installation" or os_installation"
? I'm asking because according to Michaels email, it might happen that
some tools would be writing to the file even before Anaconda is
started.
On the other hand the "spec" should be managed as part of the Anaconda
project, so naming the folder containing the config accordingly also
makes sense.

Post by David Cantrell

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

I think so.

Post by Brian C. Lane
I almost like the idea of parsing the kickstart better, it is already a
known well defined format, we already write it out, and it wouldn't
require coordinating a new thing with everyone.

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 in a
/etc/sysconfig/anaconda
file.

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Brian C. Lane]

Post by Martin Kolman
On a related note - what about the screen/spoke naming ?
The original idea was just to use the Anaconda spoke class names,
but maybe some generic naming should be used ?

Anaconda is going to be the baseline for the new API so I think we
should just use our class names. If a spoke sets multiple items it will
note that in that spoke's section of the file.

Post by Martin Kolman
Maybe one additional issue - should the folder be called "anaconda" or
maybe as something neutral, such as "installation" or os_installation"
? I'm asking because according to Michaels email, it might happen that
some tools would be writing to the file even before Anaconda is
started.

No need for a new directory in there, just a file named anaconda should
be fine.

[Vojtěch Trefný]

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the
defaults are ok for you and you're probably not going to change them later.

Maybe we could put both "visited" and "changed" to the file and let
Initial Setup (and other) decide.

[Martin Kolman]

Post by Vojtěch Trefný

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the
defaults are ok for you and you're probably not going to change them later.
Maybe we could put both "visited" and "changed" to the file and let
Initial Setup (and other) decide.

I have discussed something similar with Jiri - basically, we already
have some add-hock checking if the user changed something in the
spokes, used mostly to decide if we need to re-run some expensive
refresh operation or potentially not if the user did not change
anything.

The idea was that this could be formalized, potentially as a form of
say a "spoke access manager/monitor" that would keep track of what
spokes were entered and potentially changed.

The data could be then used both at runtime (so Anaconda can check for
changes on a spoke in consistent manner) and could be dumped to the
config file at the end of installation.

Post by Vojtěch Trefný
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jiří Konečný]

Post by Martin Kolman

Post by Vojtěch Trefný

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the
defaults are ok for you and you're probably not going to change
them
later.
Maybe we could put both "visited" and "changed" to the file and let
Initial Setup (and other) decide.

I have discussed something similar with Jiri - basically, we already
have some add-hock checking if the user changed something in the
spokes, used mostly to decide if we need to re-run some expensive
refresh operation or potentially not if the user did not change
anything.
The idea was that this could be formalized, potentially as a form of
say a "spoke access manager/monitor" that would keep track of what
spokes were entered and potentially changed.
The data could be then used both at runtime (so Anaconda can check for
changes on a spoke in consistent manner) and could be dumped to the
config file at the end of installation.

Yes, I see this as nice start for something which can be nicely
upgraded to have behavior and values what we need now or in the future.
We have now kickstart but kickstart contains only stuff you need for
system installation and it is good but sometimes it isn't enough.

Also I think we can use this as indirect spokes communication, in other
words every spoke could see if user was there and changed something
there and so. I think there is more information which could be used
that way.

As another future improvement you can done something like public and
private variables, where private won't be in the output configuration
file but only in anaconda and could be used mainly for the spoke
interaction.

[Brian C. Lane]

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the defaults
are ok for you and you're probably not going to change them later.
Maybe we could put both "visited" and "changed" to the file and let Initial
Setup (and other) decide.

The problem is we have no way to know what they intended if they haven't
changed anything. Maybe they were just exploring?

[Jiří Konečný]

Post by Brian C. Lane

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the defaults
are ok for you and you're probably not going to change them later.
Maybe we could put both "visited" and "changed" to the file and let Initial
Setup (and other) decide.

The problem is we have no way to know what they intended if they haven't
changed anything. Maybe they were just exploring?

And what about some timeout? They must be in a spoke I don't know maybe
5 seconds only then you set it as visited. I think when the user will
be 5 or more seconds he saw the settings and confirmed it even when
she/he doesn't changed it.

[Brian C. Lane]

Post by Jiří Konečný

Post by Brian C. Lane

Post by Brian C. Lane
Visiting a spoke isn't the same as changing something. I think we should
base this on changes, shouldn't we?

But if you visit a spoke without changing something, it means the defaults
are ok for you and you're probably not going to change them later.
Maybe we could put both "visited" and "changed" to the file and let Initial
Setup (and other) decide.

The problem is we have no way to know what they intended if they haven't
changed anything. Maybe they were just exploring?

And what about some timeout? They must be in a spoke I don't know maybe
5 seconds only then you set it as visited. I think when the user will
be 5 or more seconds he saw the settings and confirmed it even when
she/he doesn't changed it.

I don't think that's a good idea, the user has no way to know that's
happening.

[Michael Catanzaro]

Post by Martin Kolman
The idea is that we should not show configuration screens the users has
already visited during the installation in post-installation tools,
such as Initial Setup and Gnome Initial Setup.
An example of such a screen is the timezone spoke - if the user already
visited the timezone spoke during the installation it is unlikely to be
useful showing it again in IS or GIS. So there should be a way for
Anaconda to tell the post-installation tools what screens have been
visited by a user during the installation, so that the tools can hide
or skip the given screen.
While Anaconda already produces a kickstart file after successful
installation, the resulting commands in the file don't really map to
individual screens and there is no information about what commands have
been generated automatically, based on user action or which were part
of an initial kickstart file used for the installation. Also parsing a
kickstart file in a robust way really requires Pykickstart, which might
not be straightforward to use (at least without wrappers) from post
-install utilities not written in Python, such as Gnome Initial Setup.
Therefore a separate simple configuration file forwarding the needed
information about visited screens to post-installation tools is needed.
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
- other name/path suggestions welcome! :)
* header sections corresponding to spokes
* sections for now only contain a visited=1 key/value pair
* could be easily extended in the future to include more information
  about what user did in the spoke if needed
[DatetimeSpoke]
visited=1
* it seems sensible to write sections only for spokes that the user
  visited, not all spokes
* all sub-classes of the Spoke class should be recorder if they are
  visited, including addons
* Initial Setup will also need to record spoke visits as there might be
  another setup tool chained behind it
  (and GIS indeed runs after IS on RHEL7)
* should we also report hubs the user has visited ? at least for now
 
the number of hubs and their order are fixed
Looking forward to your feedback! :)

Hi,

I note that your proposal is basically the opposite of the proposal
from the Workstation WG. You're hoping to reduce the number of panels
shown by g-i-s, whereas we hope to reduce the panels shown by Anaconda.
Our original proposal is given at: https://www.redhat.com/archives/anac
onda-devel-list/2015-June/msg00002.html

On top of that original proposal, we are now additionally planning to
run language selection and keyboard layout selection as soon as the
live media starts, so those will be done before Anaconda is ever
started. This is because it's much too difficult for users to figure
out how to change these currently, unless they already know where to
look in System Settings. There's been some debate about whether time
has to be set prior to installation as well, but that would be handled
by g-i-s either way. This is currently targeted for F24, but nobody is
currently working on it, so it might slip.

But your proposal would work too. Both proposals eliminate the
duplication between Anaconda and g-i-s, and that is the most important
goal here. Do keep in mind the move of language/keyboard selection;
with your proposal, we'd need to separately hide those in Anaconda.

(Our secondary goal is to reduce complexity in Anaconda, since we fear
having so many spokes is quite confusing to users who don't understand
computers.)

Michael

[David Cantrell]

Post by Michael Catanzaro

Post by Martin Kolman
The idea is that we should not show configuration screens the users has
already visited during the installation in post-installation tools,
such as Initial Setup and Gnome Initial Setup.
An example of such a screen is the timezone spoke - if the user already
visited the timezone spoke during the installation it is unlikely to be
useful showing it again in IS or GIS. So there should be a way for
Anaconda to tell the post-installation tools what screens have been
visited by a user during the installation, so that the tools can hide
or skip the given screen.
While Anaconda already produces a kickstart file after successful
installation, the resulting commands in the file don't really map to
individual screens and there is no information about what commands have
been generated automatically, based on user action or which were part
of an initial kickstart file used for the installation. Also parsing a
kickstart file in a robust way really requires Pykickstart, which might
not be straightforward to use (at least without wrappers) from post
-install utilities not written in Python, such as Gnome Initial Setup.
Therefore a separate simple configuration file forwarding the needed
information about visited screens to post-installation tools is needed.
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
- other name/path suggestions welcome! :)
* header sections corresponding to spokes
* sections for now only contain a visited=1 key/value pair
* could be easily extended in the future to include more information
  about what user did in the spoke if needed
[DatetimeSpoke]
visited=1
* it seems sensible to write sections only for spokes that the user
  visited, not all spokes
* all sub-classes of the Spoke class should be recorder if they are
  visited, including addons
* Initial Setup will also need to record spoke visits as there might be
  another setup tool chained behind it
  (and GIS indeed runs after IS on RHEL7)
* should we also report hubs the user has visited ? at least for now
 
the number of hubs and their order are fixed
Looking forward to your feedback! :)

Hi,
I note that your proposal is basically the opposite of the proposal
from the Workstation WG. You're hoping to reduce the number of panels
shown by g-i-s, whereas we hope to reduce the panels shown by Anaconda.
Our original proposal is given at: https://www.redhat.com/archives/anac
onda-devel-list/2015-June/msg00002.html
On top of that original proposal, we are now additionally planning to
run language selection and keyboard layout selection as soon as the
live media starts, so those will be done before Anaconda is ever
started. This is because it's much too difficult for users to figure
out how to change these currently, unless they already know where to
look in System Settings. There's been some debate about whether time
has to be set prior to installation as well, but that would be handled
by g-i-s either way. This is currently targeted for F24, but nobody is
currently working on it, so it might slip.
But your proposal would work too. Both proposals eliminate the
duplication between Anaconda and g-i-s, and that is the most important
goal here. Do keep in mind the move of language/keyboard selection;
with your proposal, we'd need to separately hide those in Anaconda.
(Our secondary goal is to reduce complexity in Anaconda, since we fear
having so many spokes is quite confusing to users who don't understand
computers.)

The two proposals should be viewed separately. The Workstation WG
installation experience can and should be customized for the Workstation
product, but anaconda still should have a way to ensure that duplicate
screens are avoided in instances where both codepaths are run.

For the installer, we have multiple products to support and we need to
provide the backend mechanisms to allow for different user experiences.

[Martin Kolman]

Post by David Cantrell

Post by Michael Catanzaro

Post by Martin Kolman
The idea is that we should not show configuration screens the
users
has
already visited during the installation in post-installation tools,
such as Initial Setup and Gnome Initial Setup.
An example of such a screen is the timezone spoke - if the user already
visited the timezone spoke during the installation it is unlikely
to
be
useful showing it again in IS or GIS. So there should be a way for
Anaconda to tell the post-installation tools what screens have been
visited by a user during the installation, so that the tools can hide
or skip the given screen.
While Anaconda already produces a kickstart file after successful
installation, the resulting commands in the file don't really map to
individual screens and there is no information about what
commands
have
been generated automatically, based on user action or which were part
of an initial kickstart file used for the installation. Also
parsing
a
kickstart file in a robust way really requires Pykickstart, which might
not be straightforward to use (at least without wrappers) from post
-install utilities not written in Python, such as Gnome Initial Setup.
Therefore a separate simple configuration file forwarding the needed
information about visited screens to post-installation tools is needed.
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
- other name/path suggestions welcome! :)
* header sections corresponding to spokes
* sections for now only contain a visited=1 key/value pair
* could be easily extended in the future to include more
information
about what user did in the spoke if needed
[DatetimeSpoke]
visited=1
* it seems sensible to write sections only for spokes that the user
visited, not all spokes
* all sub-classes of the Spoke class should be recorder if they are
visited, including addons
* Initial Setup will also need to record spoke visits as there
might
be
another setup tool chained behind it
(and GIS indeed runs after IS on RHEL7)
* should we also report hubs the user has visited ? at least for now
the number of hubs and their order are fixed
Looking forward to your feedback! :)

Hi,
I note that your proposal is basically the opposite of the proposal
from the Workstation WG. You're hoping to reduce the number of panels
shown by g-i-s, whereas we hope to reduce the panels shown by Anaconda.
https://www.redhat.com/archives/anac
onda-devel-list/2015-June/msg00002.html
On top of that original proposal, we are now additionally planning to
run language selection and keyboard layout selection as soon as the
live media starts, so those will be done before Anaconda is ever
started. This is because it's much too difficult for users to figure
out how to change these currently, unless they already know where to
look in System Settings. There's been some debate about whether time
has to be set prior to installation as well, but that would be handled
by g-i-s either way. This is currently targeted for F24, but nobody is
currently working on it, so it might slip.
But your proposal would work too. Both proposals eliminate the
duplication between Anaconda and g-i-s, and that is the most
important
goal here. Do keep in mind the move of language/keyboard selection;
with your proposal, we'd need to separately hide those in Anaconda.
(Our secondary goal is to reduce complexity in Anaconda, since we fear
having so many spokes is quite confusing to users who don't
understand
computers.)

The two proposals should be viewed separately. The Workstation WG
installation experience can and should be customized for the
Workstation
product, but anaconda still should have a way to ensure that
duplicate
screens are avoided in instances where both codepaths are run.

That's also the way I see it - as a complementary mechanism meant to
assure that screens shown to the user in Anaconda are not needlessly
shown in tools running *after* Anaconda.

So if a given screen is skipped in Anaconda, it can't be visited and
therefore also can't be marked as visited.

Also theoretically if any tools showing configuration screens before
Anaconda starts (as in the example above) could record these screens as
visited in the config file, Anaconda could then parse the file on
startup and hide screens marked as visited.

Post by David Cantrell
For the installer, we have multiple products to support and we need to
provide the backend mechanisms to allow for different user
experiences.

[Michael Catanzaro]

Post by Martin Kolman
Also theoretically if any tools showing configuration screens before
Anaconda starts (as in the example above) could record these screens as
visited in the config file, Anaconda could then parse the file on
startup and hide screens marked as visited.

Hm, then this proposal would actually cover our request as well... two
birds with one stone, so to speak. Anaconda wouldn't need much (or
maybe any) Workstation-specific logic, then. g-i-s could write this
file tell which spokes it should hide.

I think we could have code to write this file in upstream g-i-s, so
long as the config file format doesn't have any gratuitous Anaconda-
isms: all installers have similar screens for timezone/local/keyboard
layout/user creation, so I don't expect that to be much of a problem,
and other distros could theoretically use it if desired. The name and
location of the file doesn't matter much to us; we assume each distro
will have only one installer, so we can set it to point to an Anaconda-
specific location with a configure flag.

Michael

[Paul W. Frields]

Post by Martin Kolman

Post by David Cantrell

Post by Michael Catanzaro
On top of that original proposal, we are now additionally
planning to run language selection and keyboard layout selection
as soon as the live media starts, so those will be done before
Anaconda is ever started. This is because it's much too
difficult for users to figure out how to change these currently,
unless they already know where to look in System
Settings. There's been some debate about whether time has to be
set prior to installation as well, but that would be handled by
g-i-s either way. This is currently targeted for F24, but nobody
is currently working on it, so it might slip.
But your proposal would work too. Both proposals eliminate the
duplication between Anaconda and g-i-s, and that is the most
important goal here. Do keep in mind the move of
language/keyboard selection; with your proposal, we'd need to
separately hide those in Anaconda.
(Our secondary goal is to reduce complexity in Anaconda, since
we fear having so many spokes is quite confusing to users who
don't understand computers.)

The two proposals should be viewed separately. The Workstation WG
installation experience can and should be customized for the
Workstation product, but anaconda still should have a way to
ensure that duplicate screens are avoided in instances where both
codepaths are run.

That's also the way I see it - as a complementary mechanism meant to
assure that screens shown to the user in Anaconda are not needlessly
shown in tools running *after* Anaconda.
So if a given screen is skipped in Anaconda, it can't be visited and
therefore also can't be marked as visited.
Also theoretically if any tools showing configuration screens before
Anaconda starts (as in the example above) could record these screens as
visited in the config file, Anaconda could then parse the file on
startup and hide screens marked as visited.

I'll make it a point in our upcoming Workstation meeting to check that
whoever's working on these pre-installer screens is talking with the
Anaconda team to figure out how best to do that.

[Martin Kolman]

----- Original Message -----

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.

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
/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.

To: "Discussion of Development and Customization of the Red Hat Linux
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
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

[Martin Kolman]

So this is how I thin the "specification" could look like based on the discussion so far:

* a single config file in /etc/sysconfig/anaconda
* the file contains one section for every spoke screen present during the installation
* section naming is based on the spoke class name for every screen
* each section contains a "visited" key with value of either 0 or 1
* each section might contain one or more changed_<setting>=1 keys
* the keys are there only if the user actually changed something and always equal 1
- the idea is basically to simplify the change reporting code to only report changes,
so that we don't need to keep (at least for now) a directory of all things that can be
changed on a spoke but just trigger an action that adds the given "changed_<setting>"
line when the user actually touches something

Example:

[DatetimeSpoke]
visited=1
changed_timezone=1
changed_ntp=1
changed_timedate=1

[KeyboardSpoke]
visited=0

etc.

Also as implementing the changed_* logic is a a bit more involved than just tracking spoke
visits I propose that the initial implementation has change tracking just for the timedate spoke,
with change tracking for other spokes being implemented incrementally based on pre & post install tool
requirements.

Looking forward to further feedback! :)

Kind Regards
Martin Kolman

[Fabian Deutsch]

Post by Martin Kolman
* a single config file in /etc/sysconfig/anaconda

What about keeping it alongside of the anaconda.ks used for
installation, so in /root?

I don't see hwo such a log-file belongs into /etc.

- fabian

[Brian C. Lane]

Post by Fabian Deutsch

Post by Martin Kolman
* a single config file in /etc/sysconfig/anaconda

What about keeping it alongside of the anaconda.ks used for
installation, so in /root?
I don't see hwo such a log-file belongs into /etc.

/root/ is the wrong place to keep anything that needs to be accessed by
other things on the system. sysconfig is used to represent how things
have been configured, eg. /etc/sysconfig/kernel,
/etc/sysconfig/network-scripts/* so that other programs can pick up that
information and use it.

[Martin Kolman]

Following the feedback for V2 of the spec I have written a (hopefully
formal enough) specification document and submitted it as a pull
request[0] for the Anaconda Git repo, where the specification should
also be maintained in the future if corrections or amendments need to
be made.

The document should be pretty close to the feedback to from the
discussion so far, with the only major addition being the new
"post_install_tools_disabled" top-level namespace key, that basically
maps the "firstboot --disable"[1] kickstart command to the
configuration file.

This addition was based on user feedback, that even though the Initial
Setup tool is disabled if "firstboot --disable" kickstart command is
present, other tools such as Gnome Initial Setup, will still run. As
other tools than Initial Setup are out of scope of Anaconda the user
interaction configuration file seems like a perfect way of telling post
installation tools that the user has requested (via kickstart) that
their run should be skipped .

Like this no knowledge of arbitrary post installation tools needs to be
hardwired into Anaconda and all tools parsing the user interaction
configuration file can detect this condition themselves and cancel
their run in an appropriate way.

Looking forward to you feedback - either here or in the pull request.

Best wishes
Martin Kolman


[0] https://github.com/rhinstaller/anaconda/pull/479
[1] https://github.com/rhinstaller/pykickstart/blob/master/docs/kicksta
rt-docs.rst#firstboot

[Martin Kolman]

V2 of the final spec proposal has been posted for review:
https://github.com/rhinstaller/anaconda/pull/485

[Martin Kolman]

V3 of the final spec proposal has been posted for review:
https://github.com/rhinstaller/anaconda/pull/501

----- Original Message -----

Sent: Wednesday, January 27, 2016 3:45:32 PM
Subject: Re: Notifying post-install tools about screens seen by the user - final spec proposal for review
https://github.com/rhinstaller/anaconda/pull/485
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Martin Kolman]

Post by Martin Kolman
https://github.com/rhinstaller/anaconda/pull/501

V3 has been marked as the final revision of the 1.0 version of the spec
and pushed to the Anaconda Git repository. 

This also marks the start of work implementing the spec on Anacondas
side.

Thanks to everyone helping to design & review the spec! :)

Post by Martin Kolman
----- Original Message -----

To: "Discussion of Development and Customization of the Red Hat
Sent: Wednesday, January 27, 2016 3:45:32 PM
Subject: Re: Notifying post-install tools about screens seen by the
user - final spec proposal for review
https://github.com/rhinstaller/anaconda/pull/485
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Martin Kolman]

Post by Martin Kolman

Post by Martin Kolman
https://github.com/rhinstaller/anaconda/pull/501

V3 has been marked as the final revision of the 1.0 version of the spec
and pushed to the Anaconda Git repository. 
This also marks the start of work implementing the spec on Anacondas
side.

The work has been started on the Anaconda implementation of the spec,
the parsing & writing of the config file is more or less done and next
is the actual integration with Anaconda, so that it respects the config
file and correctly records spoke visits.

I plan to have the implementation ready for the F25 timeframe with a
reasonable margin.

Post by Martin Kolman
Thanks to everyone helping to design & review the spec! :)

Post by Martin Kolman
----- Original Message -----

To: "Discussion of Development and Customization of the Red Hat
Sent: Wednesday, January 27, 2016 3:45:32 PM
Subject: Re: Notifying post-install tools about screens seen by the
user - final spec proposal for review
https://github.com/rhinstaller/anaconda/pull/485
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list