Susan Sohn wrote: > There will be a review meeting on Monday, June 8, to discuss the functional > spec for the Client redesign. The spec can > be found here: > > http://www.opensolaris.org/os/project/caiman/auto_install/ai_client_func_spec_0604.pdf >
While I'll be on the call, I thought writing down my comments would be helpful as well: General comment: the transition story from 2009.06, if any is required, is not discussed here. 2.3 We seriously don't think there are any monitoring tool possibilities? 2.5 This seems to assume we have codified performance expectations for the existing client, which I do not believe is true. Should state something about the minimum memory requirements, boot performance, install performance, etc. 2.6 I'm in disbelief. There were no ideas you discussed that were judged to be out of scope for now? In fact, I see some in 5.3.2... 3.2 I would have expected this to be written in terms of the parameters consumed by the client, not in terms of what installadm will do. I'm assuming that the user could specify these interactively, right, not just pre-configure them in menu.lst or whatever? 5.1.1 Note 5: Just to be sure, you'll use the automatic sizing based on package lists when the new tag is not specified? 5.1.2.1 I'm skeptical that this change to the tags is worth the trouble. How will we help 2009.06 users transition? With respect to the NOTE, it would seem to be more precise to state that the select elements will be logically AND'ed. Finally, in regard to the "equal being subject to +- a 10% approximation": this seems redundant with providing a min/max. This would seem to impact the determinism negatively. 5.3.2 We don't do upgrades via AI, so the logic offered for zpool upgrade doesn't seem applicable. 5.5.1 More discussion of the exact user experience in tracking progress (do they have to log in? What commands would they run?) would be helpful. 5.5.2 all_client_status.log: This feels like it's not completely baked, as there's no discussion of how it's used, maintained, searched, its scalability. Why wouldn't we toss this into some sort of lightweight database, for example? Dave
