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

Jiří Konečný <[email protected]>
Newsgroups gmane.linux.redhat.anaconda.devel
Organization Red Hat
Message-ID <[email protected]>
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.

_______________________________________________
Anaconda-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.