Karen Tung wrote: > Sarah Jelinek wrote: >> Jean McCormack wrote: >>> Karen Tung wrote: >>>> Hi Jean, >>>> >>>> In a few places in your message below about requirements from the >>>> engine, >>>> you mention that the engine should "provide defined points....". >>>> Do you mean to say that these stop points would be defined by the >>>> engine? >>>> I think that it is kinda limiting to have the stop points be >>>> defined by the engine. >>>> Each installer is different and it might make sense for them to >>>> stop at different points. >>>> I think it makes more sense for the engine to have the ability to >>>> accept the >>>> definition of stop points, and be able to stop and resume from >>>> those points somehow. >>> When talking with Sarah it actually became very blurred where the >>> lines are drawn. I believe, >>> correct me if I'm wrong Sarah, that the engine redesign will have >>> more clear functional blocks. >>> Like target discover, target initiation, transfer of bits. Then we >>> have more specific code to put into >>> these blocks. Those would be the defined points to stop at. >> >> It is blurred where the lines are drawn. The way I see the engine at >> this point is that it provides common functionality used by Caiman >> installers. So: >> >> -target discovery >> -target instantiation >> -installation of bits >> -setup for postinstall tasks >> >> if we want to stop at any point during these tasks I would think the >> engine would have to define what was doable. Otherwise the user would >> have undefined results. I think that each of these tasks are stop >> points, that is that each of the above are 'atomic' in terms of >> defining a task that you can stop before or after. > Since DC will be one of the consumer of the engine, there's a need for > DC to stop at any random points of the "postinstall tasks". > That's what checkpointing and the finalizer engine allows today.
ok, good point. I can see how that is required. Those postinstall tasks must be defined in a discrete enough way to ensure that stopping and restarting is an understood set of operations. Kind of like we have encapsulated in the finalizer scripts today. > >> >> Stopping in the middle of say installation of bits doesn't provide >> anything that I can see as useful. >> > Well, for a "regular" installation, that might not be very useful, but > for DC, it is certainly very useful. > For example, > > A DC user wants to experiment with constructing an image. The user > knows that he/she would need > a "base" set of packages. He/she wants to experiment with adding some > packages to this base, or subtracting > packages from this base. So, the stop/resume/rollback feature would > be very useful for this. > The user would first install the base set, and then, "play" with any > additions or subtractions. > Of course they don't want to re-install the base set after their > experiment. So, we should be able to > checkpoint and resume from after installation of the base set. Ok, I can see the need for this. thanks, sarah ***** > > Thanks, > > --Karen
