Hi David, Thanks so much for the detailed review. Answers/comments inline...
> 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 >> > > Page 9: > - What do you mean when you say that the "Software selection service > ... [verifies] the consistency of the software selection"? Why > would the GUI allow the user to choose inconsistent software? Or > shouldn't the GUI allow another functional unit to keep the user > from choosing inconsistent software? > This statement doesn't necessarily mean that the GUI will allow an inconsistent selection of software. Perhaps the word "verification" is wrong, since it implies a post-selection process. I will work on this. That said, there are cases where users might want to select software that doesn't meet the consistency requirements. Certainly, we can't allow this in core Solaris services, but for some pkg groups, like applications, we might want to allow this. Users mix and match their own homegrown versions of stuff all the time so restricting this to enforce installation of all pkgs that show a dependency may not be the right way to go. The current install UI does allow you to select pkgs that don't meet the dependency requirements, notifies you of this, and allows you to go on if you choose. Not sure we want to take that away, but I don't think we have decided this level of detail yet. Regardless, the service itself does the consistency checking, and will work in concert with the GUI to notify the user or enforce a selection based on this. The UI's use the software selection service to get this data. > - What do you mean by "[The] Essential System Configuration service is > called to set system settings such as time zone and locale."? > I presume you mean gathering settings to be transferred to the newly > installed system during the "Configuration Phase", in which case > I think you should reword this sentence to clarify. Though it seems > that locale is something that should be used by the installer > itself. > Yes, this is what we mean. This is the replacement for the current sysidtools we have today. I will work on rewording this definition. > 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. > 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. > 4.2 Requirements, item 6: Do you mean that this component will log? > If not, shouldn't logging be left to the logging service? > This means that this service will invoke the metadata service to register the location of this script. The metadata service is the service that will allow us to store important installation configuration metadata so that the user can generate jumpstart profiles from their installed system, and other replication things we have yet to define. This requirement isn't worded correctly, I can see how this would imply this service would do the logging. I will work on this. > 5. Driver Verification Service, page 20: > 5.2 Requirements, item 5: Isn't querying repositories for the latest > versions of the driver a duplication of what the ITU Service does? > > That's an interesting question. So far we don't have the ITU doing the querying for the latest drivers, it simply takes the data from the driver verification and downloads the drivers as requested. So, in essence the ITU is simply a download and update miniroot mechanism. Along with a few other details that I am hand waving on right now. Our current ITU simply takes input from the user about where the driver is they want to update the install environment with. As I think about this it seems to me that driver verification is the correct place for this querying, and locating of the missing drivers. It is the service that is checking which devices are on the system, and has to know if it can even get drivers for these devices. So, it has as list of repositories it can look through to determine what drivers might be available for download. > 5.2 Requirements, item 6: You mean provide information on devices > missing drivers, right? > No, I think we mean provide information on the drivers that are missing so that it can provide this data to the ITU service. But, I think this is a semantic quibble here. So, yes, we have to provide some data about the devices that are missing drivers, if we can't find the drivers to support the device. There are two things the driver verification service must provide to the ITU service: 1. The locations of missing drivers, if it could find them. 2. The data about device drivers it could not find, which would include data about the device. The ITU service takes this data and: 1. Downloads the located drivers or 2. Queries the user about alternative locations for drivers that the driver verification service identified as not a part of the Solaris distro. > 7. GUI Service, page 23 > 7.1 Purpose: "Will determine system configuration data automatically > if possible."? How is the GUI qualified to do that? > > It will utilize things like NWAM or a sysidcfg file, much like it does today. It will utilize the underlying services as necessary to get any configuration data, so that it does not ask questions about data that can be found. So.. the GUI itself doesn't determine system configuration data automatically, it utilizes any tools it can to get this data. This wording is unclear, I will work on this. > 9. Jumpstart Profile Service, page 25 > 9.2 Requirements, item 1: How will you "provide automated detection of > jumpstart installation request."? Is this just a timeout of > a prompt? > No, it isn't a timeout of a prompt. We do this today. When you specify a jumpstart install there are mechanisms by which the installer knows this is what you want and it just does it. We do not want to prompt the user for anything when they specify a jumpstart install. It is completely hands off. So, the mechanism by which we determine it is a jumpstart installation request is not defined, but the requirement is that we automatically determine the user wants this so as to not have to ask any questions. > 9.2 Requirements, item 7: What is a remote software update? > This is a intended to describe that it will be able to do software updates only, not only either initial install or upgrades, which it currently does. So, basically the user could specify a profile with a remote location and ask for software that is located in that repository to be updated. Or, specific pkgs to be updated only. > 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". > 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. > 10.2 Requirements, item 6: Will all installation applications be able > to display the logs? > > Actually, this is > 10.2 Requirements, item 14: You mean "other processes are still > executing", right? > > Yes. > 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. > 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. > 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. > - What is "CSN format"? > Connected services format. For the software update manager application provided by the CSN organization. > - What is "Software Update manager"? > > A CSN product. It is available on your desktop in the Gnome application menu. It is an application which will update your system with appropriate patches depending on what your system has installed. > 12. Patching Service, page 30 > 12.2. Requirements, item 4: This ability seems similar to one of the > ITU Service. And the Software Repository Service. Should they be > factored together? > Maybe... patches, ITU's and software repository data could be in much different formats however. The patching service must know about Solaris patch specific stuff, like how to install, dependency checking. But, certainly this will interact potentially with the software repository service in terms of getting patches to install. Actually.. the transfer service would really be the place where this would all come together. The transfer service is the thing that actually lays bits down on disk, so it seems logical to consider factoring these together in that service. Let me think on this a bit... A good suggestion. > 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. thanks again for your review, sarah
