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! :)
On 11/05/2015 09:59 AM, Martin Kolman wrote:
- stored in /etc/anaconda/manual_installation.ini
- other name/path suggestions welcome!:)
Perhaps: /etc/anaconda/human_interaction.ini ?
On Thu, 2015-11-05 at 10:10 -0600, Pat Riehecky wrote:
On 11/05/2015 09:59 AM, Martin Kolman wrote:
- 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.
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
On Thu, Nov 05, 2015 at 09:11:16AM -0800, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
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.
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.
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.
/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.
Visiting a spoke isn't the same as changing something. I think we should base this on changes, shouldn't we?
I think so.
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.
On Fri, 2015-11-06 at 04:41 -0500, David Cantrell wrote:
On Thu, Nov 05, 2015 at 09:11:16AM -0800, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
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.
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.
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.
/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.
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.
Visiting a spoke isn't the same as changing something. I think we should base this on changes, shouldn't we?
I think so.
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.
On 11/06/2015 09:26 AM, Martin Kolman wrote:
On Fri, 2015-11-06 at 04:41 -0500, David Cantrell wrote:
On Thu, Nov 05, 2015 at 09:11:16AM -0800, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
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.
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.
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.
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.
/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.
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.
Visiting a spoke isn't the same as changing something. I think we should base this on changes, shouldn't we?
I think so.
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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, Nov 06, 2015 at 04:26:26PM +0100, Martin Kolman wrote:
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.
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.
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
On Fri, 2015-11-06 at 13:17 +0100, Vojtěch Trefný wrote:
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, 2015-11-06 at 15:49 +0100, Martin Kolman wrote:
On Fri, 2015-11-06 at 13:17 +0100, Vojtěch Trefný wrote:
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
On Fri, Nov 06, 2015 at 01:17:11PM +0100, Vojtěch Trefný wrote:
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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?
On Fri, 2015-11-06 at 09:25 -0800, Brian C. Lane wrote:
On Fri, Nov 06, 2015 at 01:17:11PM +0100, Vojtěch Trefný wrote:
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
On Fri, Nov 06, 2015 at 09:02:40PM +0100, Jiří Konečný wrote:
On Fri, 2015-11-06 at 09:25 -0800, Brian C. Lane wrote:
On Fri, Nov 06, 2015 at 01:17:11PM +0100, Vojtěch Trefný wrote:
On 5.11.2015 18:11, Brian C. Lane wrote:
On Thu, Nov 05, 2015 at 04:59:07PM +0100, Martin Kolman wrote:
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.
On Thu, 2015-11-05 at 16:59 +0100, Martin Kolman wrote:
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! :)
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
On Thu, Nov 05, 2015 at 11:33:57AM -0600, Michael Catanzaro wrote:
On Thu, 2015-11-05 at 16:59 +0100, Martin Kolman wrote:
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! :)
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.
On Fri, 2015-11-06 at 04:35 -0500, David Cantrell wrote:
On Thu, Nov 05, 2015 at 11:33:57AM -0600, Michael Catanzaro wrote:
On Thu, 2015-11-05 at 16:59 +0100, Martin Kolman wrote:
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! :)
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.
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.
For the installer, we have multiple products to support and we need to provide the backend mechanisms to allow for different user experiences.
On Fri, Nov 06, 2015 at 11:17:56AM +0100, Martin Kolman wrote:
On Fri, 2015-11-06 at 04:35 -0500, David Cantrell wrote:
On Thu, Nov 05, 2015 at 11:33:57AM -0600, Michael Catanzaro wrote:
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.
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" mkolman@redhat.com To: anaconda-devel-list@redhat.com 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
From: "David Cantrell" dcantrell@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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.
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
The explicit benefit here is decoupling consumers of the file from a forced knowledge of Anaconda defaults should they change in the future.
--Rob
----- Original Message -----
From: "Rob Marshall" rmarshall@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com Cc: "Martin Kolman" mkolman@redhat.com, "David Cantrell" dcantrell@redhat.com 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" mkolman@redhat.com To: anaconda-devel-list@redhat.com 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" dcantrell@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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
On Fri, 2015-11-06 at 11:17 +0100, Martin Kolman wrote:
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
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
On Fri, Nov 13, 2015 at 6:59 PM, Martin Kolman mkolman@redhat.com wrote:
- 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
On Mon, Nov 16, 2015 at 02:44:41PM +0100, Fabian Deutsch wrote:
On Fri, Nov 13, 2015 at 6:59 PM, Martin Kolman mkolman@redhat.com wrote:
- 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.
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
V2 of the final spec proposal has been posted for review: https://github.com/rhinstaller/anaconda/pull/485
V3 of the final spec proposal has been posted for review: https://github.com/rhinstaller/anaconda/pull/501
----- Original Message -----
From: "Martin Kolman" mkolman@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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
V2 of the final spec proposal has been posted for review: https://github.com/rhinstaller/anaconda/pull/485
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, 2016-02-12 at 06:52 -0500, Martin Kolman wrote:
V3 of the final spec proposal has been posted for review: 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! :)
----- Original Message -----
From: "Martin Kolman" mkolman@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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
V2 of the final spec proposal has been posted for review: https://github.com/rhinstaller/anaconda/pull/485
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, 2016-02-18 at 18:45 +0100, Martin Kolman wrote:
On Fri, 2016-02-12 at 06:52 -0500, Martin Kolman wrote:
V3 of the final spec proposal has been posted for review: 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.
Thanks to everyone helping to design & review the spec! :)
----- Original Message -----
From: "Martin Kolman" mkolman@redhat.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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
V2 of the final spec proposal has been posted for review: https://github.com/rhinstaller/anaconda/pull/485
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.stg.fedoraproject.org
-
Brian C. Lane -
David Cantrell -
Fabian Deutsch -
Jiří Konečný -
Martin Kolman -
Michael Catanzaro -
Pat Riehecky -
Paul W. Frields -
Rob Marshall -
Vojtěch Trefný