Eric J. Ray wrote: > > Well put. Doesn't this make DC effectively the "orchestrator" > from long-ago Caiman designs? Yes, that is the direction I am looking at. There are some issues and concerns with this approach though. And, many things to work out.
Perhaps the orchestrator is a combo of parts of liborchestator+DC +? Let's not jump to the conclusion at this point that DC alone, even with modifications, can assume the orchestrator role. thanks, sarah *** > > On May 5, 2009, at 3:26 AM, Karen Tung wrote: > >> Hi Sarah, >> >> When we are talking about the redesign, I often hear people mention >> about >> "modify DC so that it can work with xxxx" or "use DC to do xxxx". >> Some people are confused about what it really means. >> From what I read in the document, I feel that we are too >> focused on making DC work with AI, without talking about using >> it for other install components. >> >> At a very high level, the functionalities provided by the DC are: >> >> - manifest parsing >> - checkpointing >> - the finalizer engine, to execute any scripts specified in the manifest >> - logging >> >> Manifest parsing and logging can be used by other install components, >> but the biggest functionality we want to "share" is the finalizer >> engine. >> Checkpointing is only applicable for DC, I think. >> >> So, what we really meant when we say "use DC to do xxxx" is the >> following: >> >> Enhance the finalizer engine, which is currently only used >> by DC, so that it is general enough for all other install components >> to use. >> Then, create/update finalizer scripts that can be plugged into this >> framework, >> and try to make the finalizer scripts to be reusable by different >> install >> components. Finally, modify existing AI and DC to use this enhanced >> finalizer engine, and use many shared finalizer scripts. This flexible >> execution engine can also be used by other existing or future install >> components, for example, even the slim installer. >> >> Thanks, >> >> --Karen >> >> >> Sarah Jelinek wrote: >>> Hi All, >>> >>> Located at: >>> >>> http://opensolaris.org/os/project/caiman/CUD/Caiman-engine-redesign.pdf >>> >>> is a document that I would like folks to read prior to Wed meeting. >>> It includes the current Caiman high level design for the 'engine' >>> pieces and consumers of those pieces,and notes on areas to consider >>> in this redesign. >>> >>> Reminder for meeting: >>> >>> Wed, 5/6 >>> 9amPT/10am MT/11am CT/ noon ET >>> USA Toll-Free: 866-545-5227 >>> USA Caller Paid/International Toll: 215-446-3648 >>> ACCESS CODE: 1337371 >>> >>> It has some specific areas we need to consider, at a high level: >>> AI >>> library changes >>> DC >>> Snap/IPS >>> liveCD >>> VM Image project >>> >>> The folks who are primary developers on these projects and who were >>> asked to attend the meeting, please read this in preparation. Of >>> course, anyone who wants to participate is encouraged to look at >>> this as well. >>> >>> Feel free to ask questions, start discussion, provide comments... on >>> the alias about this. >>> >>> thanks, >>> 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 >
