Hi 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. >> >> 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. > > I want to make sure that the new customization service is capable of > handling different scripting models we have in the install land > (flash, jumpstart, solstart etc.) That's a good point. I have made a note of this and will update the document to reflect a broader scope. > >>> >>>> 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. > > That makes sense. I was imagining that it will keep on retstarting > after failure. > Nope... bad wording. I am working on changing this. >> >> 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. > > With ZFS as the base file system, the current keyword to setup BE is > not useful. I don't think populating the BE is not a separate task > with ZFS. Correct me if I am wrong. > It may mean we have to have a new keyword to use with ZFS. I haven't looked at it that closely. But, setting up and populating the BE with the current bits seems like we could do this during the same installation process. If we have the BE's setup prior to installing the bits, we could easily parallelize the work to do the actual install/populating of the BE's. Basically it would meant that both BE's were at the same version, and then the user would upgrade one later. Am I missing what you are asking here? >>> >>>> 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. > > I want to distinguish between the features/tasks that are part of > install and the features/tasks that needs to be done after > installation. It is nice to allow everyting to be setup during > install. For example creating few non-global zones during install is > good. But is it required? One of the problems with Solaris install is > that if we fail during a task, the installation is not completed. If > we keep it simple, most of installation will be successful and the > user can start working on the system. > > The second reason is that some of the features assume that the system > is up and running. The additional cases of using it during install > expose new issues. > These are valid points. The setup of a Xen DomU doesn't assume a running system. The creation and setup of zones does. But, there is nothing that says we cannot do zone creation and setup as part of the installation process after we have installed the system. There will be some issues for sure to work out. I think features/tasks that are part of install are open for debate. A user doesn't have to setup non-global zones if they don't want to utilizing our installer. But, they could. Offering them this capability may mean more failures in some cases, but it also offers them more flexibility in setting up their systems. And, it provides a 1-stop place to go to get all of this done. Us adding the ability to do these things in the installer doesn't mean that we will not still have the existing utilities that they can use post install. Your point about more failure possibilities is valid, but I don't think should be used as the gating criteria for which features we provide our customers. thanks, sarah >>>> 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. > > Thanks. > >>> >>>> 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. As for using patchpro... I don't think we have thought that much about this yet. I am aware of the patchpro product so will keep it in mind. >> >> >>> >>>> 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. > > okay. > >>> >>>> 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. > > I understand that removing/reducing the scope of a feature like > software selection is a problem because people are used to it. But if > we cannot correct it in Caiman, it will becomes a even more of a problem. > I personally don't have a concern about removing/reducing the scope of this feature. Caiman will intentionally be different and as a result likely break some usual rules. I think we just need to understand better what is the best way to do this, what our customers really want, and how to best enable it. I agree if we don't do it right in Caiman, well... then we have blown it. thanks, sarah
