Hi Sundar, A few additional comments to add to Dave's... > > >> 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. Part of the confusion in this I think is because of the way we have the customization service defined in the document. Its scope, as defined, is too narrow and incorrect based on our intended usage. 3rd party customization scripts can be run via the customization service. I am working on the document and will update this to be more reflective of what it really is. As Dave notes we have to define the mapping of this in to our services. Thank you for pointing this out. > >> 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. Dave is right, if you can't start the orchestrator you can't run an installation. The requirement that it must be self re-startable may not be quite accurate or valid. At the time I wrote this requirement the thought was the orchestrator and the other Caiman services would be all independent processes that were stopped and started as necessary. So, since the orchestrator is central to the Caiman processing my thought was it would need to be restartable and recoverable if possible. That is what I meant by this requirement. However, right now I am working on how the Caiman services are designed, particularly the orchestrator. And, if they are all separate processes, or a large process with multiple threads or some combination of that. A lot of this depends on who or what drives the services to do their work. In general the orchestrator starts up first, driving the user interfaces. During the user interface invocation the driver verification service is run. From there the user selections will drive much of the other services. Services can also drive other services.
It may turn out that the orchestrator is not a standalone process. It may turn out that the requirement that it is to be self-restartable is false, based on other factors. The requirement that it must be startable to run an install is obviously valid. > >> 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. If I read your initial question correctly, it looks like you are asking if the requirement is meant to say we will use jumpstart for doing live upgrades. What I meant this requirement to say was that from jumpstart installs we will provide the ability to do live upgrades. Currently jumpstart provides only the ability to setup an empty BE. My thought was that we should allow jumpstart users to setup and populate live upgrade BE's and then from there do a live upgrades as they wanted via another profile. The point is we should allow jumpstart to do what we can do via interactive installs and any CLI's we provide for live upgrade. > >> 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? > By default the install will do what you suggest, simply lay the bits down on disk. But, we will allow our users to customize their systems and installs. I don't think the addition of requested features implies a slow down in the installation process or even a buggier implementation. Why? I think the key thing here is that the Caiman architecture encapsulates the functionality for each feature and tries to keep the modularity in tact so that we don't have overlap and duplicate functionality in multiple services. Your concern about additional complexity is valid, and certainly the way we have had to add new functionality to the existing installer backs up this view. But, the existing installer architecture has degraded such that there is no clear distinction or lines between functionality. And, thus when adding new features we have to touch a lot of code. This leads to bugs and duplicate code. And, a maintenance nightmare. The Caiman architecture is intended to alleviate this issue. All the services we have defined either separately or as some combination of services supply the features you refer to above. To allow the features to be utilized in jumpstart doesn't really add to the complexity of the installer. The features are there in the services, enabling them in jumpstart is just a straightforward step. Part of what we need to provide is support for our own technologies. Which means we must provide the ability to install and support our own installation target environments, such as Xen, and zones. We don't do a very good job of this today. The other feature you mention, the ability to support software add/update only is simply an artifact of the software repository service. Enabling this in jumpstart via new keywords is really trivial. I think you will find that the modular nature of the architecture proposed will help alleviate some of your concerns. Will we have bugs, presumably. But, we will be able to isolate functionality in such a way that fixing them or adding additional capabilities is more contained and understood. At least that is our intent. >> 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 ;-) I am going to update the document to better explain what this means. > >> 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. yep, it is a typo. It should just be 1 item on the list. That is the patch service must be able to be invoked in jumpstart mode. > >> 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". Actually, this requirement is intended, if not explicitly stated in the requirement list. We want to use standard system utilities if at all possible to do normal configuration tasks. The description mentions this. Maybe I should add an explicit requirement. > >> 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. One other thing to keep in mind is that software selection may not be what we know it to be today. We are talking about adjusting the clusters of software to be more intuitive in terms of what they mean, not just some arbitrary clustering like we currently have. Another thing we are talking about is allowing the ability to select and deselect clusters of software, not individual packages. Although, I imagine if we went this route we would get a lot of pushback. sarah
