Hi Sundar, Sundar.Yamunachari at Sun.COM wrote: > Dave, > > It took me a while to go thorugh all the mail messages. > > Dave Miner wrote: > >> >> 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. > > I want to make sure that the customer doesn't need to setup anything > (like the current live upgrade) to do the upgrade. We are planning an automated BE setup during initial installation so that the customer doesn't have to worry about setting this up themselves. Of course, we will have folks that are current Solaris users that will have to migrate to our new strategy. This will require some manual intervention on their part. > >> >>> 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. > > If you are referring to the install time locale, it makes sense. > >> >>> 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. > > When I read the document, it mentioned only jumpstart scripts > (begin/finish) and so I want to make sure that we consider the > solstart feature before deciding what to do with it. > The customization service is intended to be more than jumpstart begin/finish. I will make that clearer in the document. >> >>> 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. > > The flash scripts are different in the sense that they are needed > while creating the flash and also has more combinations like > before/after creating the flash and before/after extarcting the flash. > Since flash is used in jumpstart, live upgrade and interactive > install, the flash designers wanted more flexibility. The jumpstart > customization mechanism is not flexible to be adopted for flash. So it > was differert from jumpstart. I was thinking of an example that uses > flash archive with jumpstart install. It is also possible that > customer might use multiple finish scripts to configure different > software. Also JET does uses jumpstart scripting to setup JET scripts. > This is good data to have. >> >>> 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? > > 4. Will support full image installations, advanced deployment > installations, and live upgrades. > - advanced deployment installation is too open-ended and it might > include anything and everything. That's fair. And, it is intentionally ambiguous since we don't know which advanced deployment installations we may provide at this time :-). > 5. Will support creation of non-global zones and creation of Xen DomU's. > - I don't think creating zones is part of install/upgrade. I disagree. I think any target support we currently offer in Solaris should be creatable and installable via our installer. > 10. Will provide support for software add/update only(without an > installation type of keyword). > - The initial install/upgrade should install the software that > comes in the WOS. All additional install/update should be done after > boot. If you are talking about packages outside WOS, there is a > keyword already in jumpstart to install them Yes, but the keyword only works if you are doing an install or upgrade. The idea is to allow this keyword to standalone and add/update software only.
>> >>> 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? > > For example, if we are asking user for locale using a tool during > install, the same tool/interface may be used to change locale after > install. > > I mentioned patchpro in my comments. If install invokes the same tool > to install patches during installation, it helps the user to have > consistent interface during and after install. > We are planning to have consistent system utilities during and after install. Not sure about the patchpro stuff specifically, but I understand what you are getting at. >> >>> 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. > thanks, sarah *** > We needed to detect just to ignore them. > > - Sundar > >> >> Dave > > >
