On 01/12/10 04:16 AM, sanjay nadkarni (Laptop) wrote: > Caimanics, > Please review the requirements documents for replication in > OpenSolaris. This provides the the Flash type functionality but > includes support for zones. >
Intro: I don't think there's anything preventing zones from being included in a master image created by DC and deployed by the GUI or text installer. Getting the zones configured correctly after deployment of the image is likely an entirely manual process, but otherwise I don't know of a reason this couldn't work. To me, the main reason replication is desired is that it can be hard to script up all the things you'd like to configure into DC scripts; replication allows for a manual build-out of the master and then fast, reliable duplication. Interesting distinction of replication vs. recovery. I'd never put it quite that way, but I think it's probably the right expression. Goals: You didn't mention zones p2v here; probably should be explicit one way or the other. Requirements: 5. I don't see how compression is related to portability, nor why multiple compression options relate (or are even required, though I agree that multiple should be possible, which is what I think you really meant to say here). 7. I'm not following how the packages would get used, or why it's this tool's problem; it seems like a requirement on the installers that are deploying such an image to appropriately deal with attributes of the system. Otherwise you're seemingly creating the requirement that the creation tool must be omniscient about all possible architectures that the image might be applied to in the future. Metadata: Why is IPS publisher info necessary in the metadata? How would we use it before the image is actually laid down, at which time we can just grab it from the image itself? Similarly for zones and other system configuration. Broadly, is our goal to replicate both the contents and the configuration, or just the contents? Goal 1 seemed to imply the latter to me, but the use cases seem to be leading toward the former. Need clarity here, I think. The pool information seems orthogonal to replicating a BE. It seems possibly more applicable to a recovery scenario, though I can't say I've entirely convinced myself of that, either. Requirements on other projects: I'm not sure installadm is the tool to provision the master images. One approach that occurs to me is to publish the stream as the contents of the package (might need a new action type for that to do it well), with the metadata expressed as tags of that package. This seems to meet most, if not all, of the Requirements and might limit the necessary changes in the applications a bit. Dave
