Hi Joe,
> Ethan Quach wrote: >> Sarah, >> >> 1.4.a Can you clarify whether or not we're discovering >> UFS instances of Solaris? Or does the lack of >> specification imply UFS and ZFS? >> >> 1.7 Same comment as above really. >> >> 1.6 and 2.9 I don't recall. Are these requirements >> meant to satisfy usage by libbe, or to express >> functionality provided by libbe? >> >> thanks, >> -ethan >> >> >> >> Sarah Jelinek wrote: >>> Please review and provide comments by COB Wed, 6/17. >>> >>> thanks, >>> sarah >>> **** >>> >>>> Hi All, >>>> >>>> I have posted a set of requirements defined for the Caiman unified >>>> engine. They are located at: >>>> >>>> http://opensolaris.org/os/project/caiman/CUD/cud_req.txt >>>> >>>> There are some more details that need to be added, specifically >>>> with regard to observability requirements. A lot of that depends on >>>> the consumers of the unified engine. Along with the error handling >>>> section. >>>> >>>> Please review and send comments. >>>> >>>> Regards, >>>> sarah >>>> >>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > > JJV Item 1: > ----------- > 5. Must provide support for development and testing. > > Should support for remote access be called out here? For example both > the GUI and AI provide a mechanism to enable SSH to aid in testing and > diagnoses. Should providing this type of hook be a requirement of the > engine? Yes, I believe it should be. I will add. > > > or would this fall under #7? > No, I think it is under deveploment and testing. > JJV Item 2: > ----------- > > 9. Must provide a way for consumers to specify an override for any of > the functional pieces provided by the installation engine. > > > Sorry but I'm just a bit confused as to what this point means. > > Is the intent to allow users to provide there own plug-n-play > mechanism to provide a specific engine function? > > I think this should be more specific. What are all of the functional > pieces provided by the engine we expect to allow users to override? The requirement is really that we need to make the 'engine' extensible. The data we have at this point on how we are going to do that, and what functionality we might have to do it for is limited. What we do know is: -DC has specific needs with regard to how the 'installation' flows. Compared to other Caiman consumers. We have to provide a way for DC to get what it needs in terms of the engine functionality and the order in which the functionality occurs. DC has specific needs with regard to the finalizer scripts. The requirements here are unique to the DC, but we do know that some of the requirements with regard to those are captured in other places. Specifically: -Must export stop and start points for consumers -Must support for restarting at any previously successful step The other, more nebulous requirements are around the 'pluggability' of the DC finalizer scripts. Right now DC allows for random pluggable scripts. There are no boundaries really, except for the standard args they export as required. The extensible requirement comes partly from this as well. I will modify the requirement to say must be extensible. Pluggable is a design choice which we have not made. Thanks for the comments. sarah **** > > Thanks! Joe > > > > > > > >
