On Thu, Jun 4, 2009 at 2:38 AM, Sundar Yamunachari<sundar.yamunachari at sun.com> wrote: > Hi, > > The requirements for setting up system configuration is posted at > > http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/system_configuration_parameter_requirements.pdf. > Please review the document and provide your feedback before next Wednesday > (06/10/09).
I think we're being too modest. I can think of the following cases where I would want to set up system configuration: (a) Derived from Automatic Installation (b) Supplied by the user during an interactive installation (c) Supplied by the user at first boot (d) Supplied by a user who's changing a running system (e) Blanking the configuration (f) Replacing the configuration with a new one I think (a) is reasonably obvious; for (b) we have the case where the installer prompts for the information and applies it for you; in (c) we have the case where an installed system prompts for information (either because they've just installed it or because it was shipped that way by their supplier); (d) may happen at any time; while (e) is the sys-unconfig replacement, and (f) is what I've often wanted to do with sys-unconfig - specify the new configuration so it gets picked up automatically rather than prompting. Mapping these to users, I expect enterprise users to be using (a), (b), and (f). The user/developer target of Indiana is likely to be interested in (c) and (d). I suspect this ends up with some sort of configuration repository. I'll skip over what that looks like, but having such a repository would allow the easy backup, restore, and replication of the configuration. (A simplistic implementation might just list what's configured and where; a more sophisticated version might also contain a copy of what the actual configuration is, so that it can be used to validate and fix the current system.) We're basically talking about sysidcfg. It may be worth thinking about what's wrong with that, which includes off the top of my head: - Difficult to extend to add new functionality - Too much domain specific knowledge embedded in its internals - Zero integration with other tools managing the same configuration Going through the requirements, some immediate notes: 1.1 What's with this compelling user experience thing? I don't want to be compelled - I would much rather not experience it at all. Given that you're going to have to interact with it, the key qualities I look for are that it be simple and streamlined. 1.2 Configuration of system during installation from LiveCD seems to be missing 1.2 I'm not sure I understand what 3 and 4 are - do we support installation directly from an IPS repo? 1.2 Case 7 I think it's important that we work out how reconfiguration of properties interacts - while we shouldn't aim to solve the general configuration problem here, I think that declaring it out of scope simply reinforces the unfortunate separation between install-time and run-time configuration 1.3 At a basic level, automatic or manual network configuration? 1.3 Routing goes way beyond a default router (although I've always been fortunate myself to have always dealt with the trivial case). 1.3 There's the whole name-service area 1.3 Web proxy configuration (especially important if we're limited to a network- centric packaging system) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
