Hi Dave, Thank you for the review and your comments. Answers inline...
> Sarah Jelinek wrote: >> Hi All, >> >> I have posted the first public draft of the proposed Caiman Unified >> Engine Functional specification. It is located >> at: >> >> http://opensolaris.org/os/project/caiman/CUD/CUE_docs/CUD_func_spec.pdf >> > > 2.1: In general, I think most of requirements could use a bit more > prose, they seem a bit too terse and leave lots of room for > interpretation. A nit: "zpool datasets" -> "ZFS datasets" > Ok, fair enough. I will beef these up with more data. > 2.1.3: Why is this specific to non-IPS installation? > I assumed the requirement for getting size was on the IPS team, not the engine itself. Really, however, thinking about this, the engine should provide the interface to get the size data, regardless of how it gets that data. The consumers should be shielded from this. I will modify this requirement. > 2.1.4: Why is the engine responsible for validation of data that > appears to be understood and interpreted by specific modules? Or are > you suggesting that the engine will provide an infrastructure to > enable modules to provide validation? > The requirement is simply to have validation occur as part of the installation processing. The requirement isn't stating anything about how this is done, just that we have to do it. However, this is not clear in the document. We did not indicate in the more detailed functional sections that the modules will be doing validation that is appropriate to their function. I can see that this would be confusing. I will modify the document. The intent is that that modules understand and do validation that makes sense for their function. > 2.1.8: This one really needs clarification. My expectation was that > the overall architecture provides it, not that there's a specific post > installation framework. > I agree. I will rework this. The architecture does provide this. What I was trying to say is that post installation configuration support has to be provided. > 2.1.9: Definitely need clarification on what "transport independent" > means. > Ok, will work on this. > 3.4: To me, a transition plan is more appropriate as something like an > appendix; it's more a "how", not a "what", which is where I think the > primary orientation of a functional spec belongs. > Ok, I will move to an appendix. > 4.1.4.1.1 - it seems to me that there may be cases where limiting the > scope of target discovery could be useful, if not necessary, > (installadm is one that comes to mind), hence some inputs may be > warranted. > That's an interesting thought. The initial thought was that the common target discovery would do the things that we have outlined, and if consumers needed different or specialized target discovery they would provide their own consumer specific module. Your thought is that allowing for inputs makes this module even more re-usable? > 4.1.5: As you have a number of references to the data collection > object before this point, I'd suggest moving its description earlier > in the section. I would tend to think of this as a service in the > same vein as the items in 4.1.6 (as it has similar characteristics) > but perhaps that's just me. > It is a service. I was never comfortable with the use of the term 'object', but couldn't think of how else to express it. However, 'service' makes sense. I agree as well that I should move it up as it is critical to understanding the use of it. > 5.1: I'm curious as to the attributes of "R&R client" that led you to > classify it as more different than like the installers, but perhaps > I"m not understanding what you mean by R&R client here. What is meant by R & R client is the client utility that creates the actual 'archive' of a system. Not the installer that installs that 'archive'. It is a command that the user runs to copy off a systems data, systems identity, etc... to use for replication and/or recovery. The reason it is different, or that I was thinking it was different, was that much like DC, it has pretty unique needs with regard to things like target instantiation. It's target is much like DC has today, a build area that it can create an image in. R & R client works similarly in that its output is different than that of the other installers. > > 6.2: I'm not clear what is meant by a "network 'target'" that requires > discovery for the text installer. Can you clarify? > What is meant by this is the following: -network interface discovery -nameservice discovery -existing netmask or ip information These are 'targets' for installation in the sense that we will be allowing users to configure these as part of the text installer. Discovery of these has to happen somewhere and it made sense to me that this belongs in the Target Discovery module, but that most other consumers wouldn't make use of this data. Does this make sense? Thanks again for the review. sarah
