Hi Sarah, Forgive me, but I haven't as of yet had a chance to read through anyone else's comments or your replies to them. If any of my comments are addressed elsewhere, let me know.
General impressions: I think this looks really solid. At least, I think about what the installers might look like in this framework, and it seems like a Good Thing (tm). From a terminology standpoint, the word "class" seemed to be used in capacities in the document, at least to my eye. In some cases, it seemed to refer to a literal object-oriented type class, while in others, "class" seemed to mean something more like 'module' or 'component' (i.e., a larger "grouping" of sorts). Checkpointing: In section 2.1, it says the 'list of checkpoints is defined by the application.' Since we're talking install phases here, I'm assuming checkpoints mean more than they do in the DC sense. DC checkpoints are ZFS snapshots (plus some other bookkeeping); in a full install, in the early stages we don't have a zpool set-up yet, so the checkpoints have a different definition. Am I right in assuming that the checkpoint definitions have to include how to "rollback" to the starting point? Is that part of the 'cleanup_checkpoint' functionality, or is that different? Loggers and "Progress receivers": These two concepts seem very similar in function (although not in the data they receive). One thought I had was that, if each logging statement were composed of the following data, then the progress receiver(s) could be a special logger that only consumes certain portions of that data. - Current time - Current progress % - Estimated time remaining - Message string - Optionally, location in code (execution stack or file name and line number, for example) 2.1 Execution Engine: I know this isn't a complete API, but for the cancel() function, is this a "safe" cancel? Will we have a way to stop_at_next_checkpoint() or something similar? get_loggers() vs. log_message() - For logging, what is the expected usage: log_message(), or iterate through the loggers from get_loggers() and log things explicitly to each? (Am I getting too low level here?) 3.1 Manifest Parser: parse() - it seems like the data collection classes may need to implement this interface in some fashion as well, yes? 3.2 Target Discovery: We have DeviceTarget as a base, and LogicalTarget as a base. Is there a common base for each (even if it initially provides a very minimal interface)? 3.2.1.2: Logical Device: What is the DeviceTarget equivalent of instantiate()? 3.4 Transfer Data: I'm assuming get_type() returns cpio, IPS, etc. Would it be better to subclass TransferData based on type? 5.3 DC: How do DC's current 'checkpoints' relate to the 'checkpoints' of the install engine? Will each finalizer be an install engine checkpoint? Or are they different concepts? - Keith Sarah Jelinek wrote: > Hi Caimaniacs, > > I know you have been waiting for this bestseller to hit the shelves! :-). > > The Caiman team has been working on an updated architecture and we > have the architecture document ready for review. The > opensolaris-caiman project architecture page is located here(formerly > known as Caiman Unified Design): > > http://hub.opensolaris.org/bin/view/Project+caiman/CUD > > The Caiman architecture document open for review is located here: > > http://hub.opensolaris.org/bin/download/Project+caiman/CUD/caimanarchitecture.pdf > > > > Please send comments/questions to caiman-discuss by 12/18/09. If you > need more time please let us know, with the holidays coming up we may > have to extend the review period. > > Thank you for your time. > > Regards, > sarah > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
