Dave Miner wrote: > 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. > Agreed. I will fix that.
> 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. > Sarah mentioned that too. I need to think about this a bit more to understand the ramifications. > 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). > I was really thinking about portability in terms of size i.e. easy to move it around. An uncompressed image can be 10's of GB. While it can be moved, its not easy. > 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. > I was unclear. By the term "tool" I mean the installers need to provide the ability to add pkgs.I do expect the installers to provide the capability to add pkgs. The only reason to include the IPS repo information in the image is a hint as to where to pick up the pkgs. Of course I expect this can be overridden. I also realized that I missed capturing this requirement as a requirement on other projects. > 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? The IPS publisher information was included as a hint to the installer to pull in the required pkgs. For reasons I cannot fathom now, I was conflating the need for this at install time. That of course is not required since the system will already be running. > Similarly for zones and other system configuration. Broadly, is our > goal to replicate both the contents and the configuration, or just the > contents? Here's I was mainly thinking about providing better information about contents of the image. For example, users could create one master image which based on a system with 2 zones which are configured for Oracle with 2 VNICS. Another image could have 5 zones of with 2 are configured for Apache webservers and others have MySQL. As a user I would like to know the contents of those archives. > 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. I was approaching this with the idea that the image should not only replicate the BE, but should also provide a hint of the type of stability required. for example mirrored root. The ability to override this must exist. But again, if a user queries the image, it would be useful to have this type of information when choosing the target system. > > Requirements on other projects: > > I'm not sure installadm is the tool to provision the master images. I would like to think about this a bit more. > 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. That jives with my thoughts too. > This seems to meet most, if not all, of the Requirements and might > limit the necessary changes in the applications a bit. Can you elaborate ? -Sanjay > > Dave > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
