Quoth Sarah Jelinek on Thu, Dec 07, 2006 at 10:22:46AM -0700: > >Quoth Sarah Jelinek on Wed, Nov 08, 2006 at 01:21:48PM -0700: > >>We have completed the first draft of the Caiman install project > >>architecture document and have posted it for review. > >> > >>You can get it: > >>http://www.opensolaris.org/os/community/install/caiman_arch.pdf ... > >3. Channel Service, page 18: > > - What does "During an interactive installation, provide the ability > > to provide of streaming data." mean? How is this different from the > > logging service? What is being channeled, and between what? > > Logging service is for logging the installation process details. The > Channel service is really about streaming things like marketing type > data to the installer during an interactive installation. Think MS > installations with all their marketing messages, and help messages. We > are planning a similar service. We can utilize this service for a lot of > stuff. Like, providing the info for developers to register with Sun > developer network, or hooking them up to our planned opensolaris > repositories. This service is simply a data service that allows us to > send data to the interactive installer. This will work from DVD as well > as we can prepackage our streaming data and include it on the DVD.
Ok. I think "Advertising service" or "User information service" would be a more appropriate name. > >4. Customization Service, page 19: > > 4.2 Requirements, item 4: Is this a finish script? > > Yes. this is exactly what this is. But, it allows the users during > interactive install to specify a set of scripts they want us to run to > finish with their customization, prior to reboot. Currently, finish > scripts are only available via jumpstart. Ok. I think it would be useful to explicitly compare against finish scripts. ... > >9. Jumpstart Profile Service, page 25 ... > > 9.2 Requirements, item 9: Can you provide motivation for "support to > > upgrade from a partial repository."? > > Currently today we support upgrade from a full Solaris distribution > only. Even with live upgrade. Which implies a lot of things could > potentially be upgraded, and a lot of work has to be done in the process > of doing the upgrade. Our thought are that perhaps users want more fined > grained control of what gets upgraded. If there is a partial repository > of software that they have or have developed or we provide, allowing > them to upgrade from that repository of software seems like a good > feature to provide. Certainly we can't do a partial upgrade of core > Solaris kernel services if all dependencies are not met. But, in the > application space we can allow for repositories that update only certain > pieces of Solaris. > > Maybe this requirement should really be worded something like "Will > provide support to do partial upgrades". Yeah. It seems to me that a better way to avoid upgrading things is to tell that to the installer rather than removing them from the software store. > >10. Logging Service, page 27 > > 10.2 Requirements, item 4: Do you anticipate that the logging service > > will have a lot of bugs? > > No, what this requirement means that the logging output will be in debug > mode to allow developers to get more data. Which will not be the default > setting. Isn't that the same as item 3 then? > > 10.2 Requirements, item 6: Will all installation applications be able > > to display the logs? > > Actually, this is Could you elaborate? ... > > 10.3 Non-Requirements, item 1: I think log messages are typically > > exempt from localization. Are you planning otherwise? > > I didn't know this. If this is the case, then I guess we don't need to > worry about this. It has certainly been the case with the SMF daemons. > >11. Metadata Service, page 29 > > - The metadata service is not mentioned in the Introduction, though it > > does appear in the diagrams. Why is that? > > I am not sure what you mean by not mentioned in the introduction, it is > shown in the dependency diagram. No other service is mentioned in the > intro, unless I am misunderstanding you. Yes, sorry, I meant "2. Orchestrator service", since that describes the overall process. > > 11.1. Purpose > > - Can you give some examples of the metadata you will be storing? > > Sure... things like data about which pkgs are installed, layout and > space assigned to filesystems, patches installed, zone configuration. > Things necessary for us to be able to generate a jumpstart profile from > this data. And, to provide the Software Update manager the necessary > data they need to know how to upgrade/update the system. There could be > other things as well, depending on how we decide to move forward with > representing replication metadata in other forms. Ok. Please add that to the document. > > - What is "CSN format"? > > Connected services format. For the software update manager application > provided by the CSN organization. Ok. Please explain that in the document. ... > >13. Post-Install Service, page 31 > > 13.2. Requirements, item 1: What are "default post-install actions"? > > Depends... things like as much of the system configuration that we can > defer until after install has completed is part of what could be default > post install actions. Things like firewall/security settings, or adding > additional user accounts. If you look at other installers like the > Ubuntu installer, a lot of things are deferred until after 1st reboot. > The intent is to get the system installed and running and then ask > additional questions if required. We haven't defined this any further > yet but certainly need to do so. Ok. But I think you need to reword the item to something more like "Will execute default post-install actions, like ...." Optionally with "The full list of default post-install actions is specified by X via Y." David
