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.
Hi Karen, Thanks for the review. It isn't my intent to make it seem like we only want the changes to DC for AI. I do mention that I need DC to do a lot of things, in particular to support all forms of the installer. If we do decide to make DC be the 'engine' in Caiman. > > 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. > Yes, the finalizer engine is a big part of what we need to share in DC. > 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. > Yes, exactly. Better put than my doc. I will update my doc to make this clearer. It is a bit more than this though.. We have to figure out how to get DC to operate in a way we currently need for some of the other pieces of functionality that are provided in liborchestrator. The orchestrator was our initial attempt at an install engine. It works well actually, but with the overlap with DC, we need to assess the feasibility of providing some of the functionality in some way with DC that we rely on in liborchestrator. This isn't an install component specific thing, it is a functionality requirement. thanks again for the review. sarah **** > 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 >
