Sundar.Yamunachari at sun.com wrote: ... > > Sarah, > > This is an excellent document. These are my comments. >
Thanks for your comments, Sundar. > 1. "in-place upgrade" is not supported > There are few comments regarding this topic. Right now "in-place > upgrade" is straight forward. It is almost similar to "initial install". > Are you planning to keep the simplicity when the user choose to do > upgrade with caiman? If you do, this will help the users who rely on > "in-place upgrade" simplicity to get new bits. > Your argument appears to be that that current "standard" or "in-place" upgrade is simpler for the user than the current Live Upgrade, and on that point, I agree. However, an upgrade system which combines the best features of the two, which is what we're really talking about here, seems preferable. Or perhaps I'm misunderstanding your comment. > 2. Page 9: "The process of selecting software is driven by the usage of > the system rather than software bundles. This approach greatly > simplifies the choices presented to the user without assuming a Solaris > centric bias. Thus software selection is based on system usage, i.e., > desktop, server or server and desktop." > Will there be customization of software? For example if I want > desktop but I don't want staroffice, Can I customize using gui? > Yes, customization is supported, the mockup that's been posted shows a bit of this already if you go to the "Installation" step and check out the Software tab. Some features of the software selection service are designed to support this functionality. > 3. Why timezone and locale are considered to be essential? Can install > proceed with out them? Is locale is required to determine the locale > packages to be installed on the system? > We need the locale in order to communicate with the user in the correct language. Timezone isn't strictly necessary from an operational point of view, as the system really doesn't care, but it helps with usability of the install if the system's time representations in the logs and so on are what the user expects. > 4. Currently we have a install piece called 'solstart' which is similar > to jumpstart with begin and finish scripts. It is typically used to > install essential patches that comes with the image under > Solaris_XX/Patches directory. Also it is used by SunFire 15000. Solstart > is used interactive installs and jumpstart. Is there any plan in caiman > to allow third party customization scripts to be run before and after > solaris install? > The customization, patch and post-install services are intended to fulfill some of these requirements. SolStart presents a particular interface for which we'll need to provide compatibility; fortunately, since it's essentially an extension of the existing Jumpstart services that shouldn't be too difficult if we're also providing Jumpstart compatibility. We certainly need to define at some point how this maps in. > 5. Section 2.3 -> item 3: What do you mean by "Must be self re-startable > in the event of failure"? What if it cannot start after failure? > This requirement is for the Orchestrator. If it can't be started, then you can't run an installation. > 6. Section 4.2-> item 6: "Will provide logging and debugging facility". > What kind of debugging facility you are talking about? It is going to > call a user provided script/program. Are you referring to all the > debugging tools available to the user at that point? > Most likely we'd be talking about interfaces to communicate a debug mode to the external programs/scripts, or something like that. > 7. Can we attach multiple customization services to be run for a single > install? Also it looks like this is planned only for jumpstart? What > about interactive installs? Also we have a separate script mechanism for > flash. Do you have any plans of making that a customization service? > No, it's not planned only for Jumpstart, requirement #1 in 4.2 is specifically that it also runs in the interactive installation. I would expect we could support multiple such services, though it's not clear to me what the use case might be; got any good examples? I would expect that we'll unify whatever flash turns into to use this same service. It's not clear to me why we have the separate one today. > 8. Section 9.1 -> item 5: "Will support full image installations, > advanced deployment installations, and live upgrades". Are you planning > to use jumpstart to do live upgrade? Currently live upgrade uses > pfinstall (which is essentially jumpstart). > It would be one option. Basically, the idea to keep in mind is that you can do any of the installation upgrade tasks from either an installed Solaris instance or one that's booted from media. > 9. Section 9.2: We want to simplify installation. I think installation > should be fast and simply install the bits on the system. Any additional > configuration should be done after reboot. Looking at the requirements, > we are adding additional features to installation and will eventually > slow down things and become buggy. I am referring to section 9.2 items > 4, 5 and 10. > I'm not sure I understand what you're objecting to. What features should we not provide? > 10. Section 10: Logging service. What will happen to the current logging > mechanisms in jumpstart? Will it be rewritten to use the logging service? > Presumably. > 11. Section 11.1: What is CSN format? > CSN, aka SysNet, is the organization responsible for Update Connection. We don't know the specifics, but the point here is that the metadata we collect is similar to data that UC collects, and might be worth unifying or leveraging them. Much hand-waving here ;-) > 12. Section 12.2 -> item 7: "Will support rollback to pre-patch system". > What is the reason behind supporting the rollback? How is it useful for > Jumpstart? It is supposed to be "hands-off". Also do you have any plan > of invoking services by patchpro as part of install/upgrade to do the > patching? > I think there's a typo here, in that the "Must run in Jumpstart" was merely one item in the list. However, even so, an ability to revert to the pre-patched state seems orthogonal to the type of installation performed. This service most likely involves additional coordination with the Update Connection team. > 13. Section 13.2: It is nice to have the following requirement: "May be > able to use the same tools that is used for post-install service for > normal re-configurations". > I'm not sure I understand what you're looking for; got an example? > 14. Section 13.4: Looking at the "Services Dependent on", the > Orchestrator service will be running after reboot. Will the Orchestrator > service run on the system all the time? > Unclear at this time, but I don't necessarily expect it would. Starting it on demand would be sufficient for most uses, I think. > 15. Section 14: "Software Repository Service". How does this service > work for media installation with out network? Can the installer provide > another media? > A repository doesn't have to be an entity out on the network; a piece of media would also be modeled as a repository, which is sort of what the existing cdtoc and friends give you today. > 16. Section 15: "Software Selection Service". Can we remove this > feature completely from interactive install? If you look at the current > distribution there are 180 "clusters" and lot of them are not > interesting. Unless we create a supercluster (group of clusters) or show > only clusters that is meaningful to customize, it is going to be mess. > I'm not sure how far down that path we're going to go yet. The minimizers are an especially vocal and militant religious group that we're unlikely to be able to ignore. I agree that the existing clusters are problematic from a usability point of view, since they're not designed from that perspective but more often based on some particular componentry that our engineers have imagined to be useful. > 17. Section 16.2 -> Item 3: We may have to detect Veritas File systems > also. > Depends whether we have the information needed, and where it falls in the priority list. Our intention is that we'll provide interfaces which would allow anyone to extend the services for cases we don't necessarily support, so that it's not necessarily something we have to do. Dave
