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 Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
