On 01/21/10 12:12 AM, sanjay nadkarni wrote: > 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.
Mobility is perhaps the term you really want to use. But on 1G or 10G networks, moving 10 GB isn't actually that time-consuming, so while I don't have a problem with defaulting to compressing these things somehow, allowing for non-compressed seems trivial. >> 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. OK, I understand better what you're trying to solve. > >> 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. I don't quite buy into the image *requiring* a particular storage configuration. Information on what the original configuration was seems like it could be helpful, I suppose. >> >> 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 ? > If the stream is just a package that gets laid down, there's very little additional work required in the installers - we already know how to install packages. The only thing that would seem to be necessary to add to the installer then is to de-encapsulate the installed image from the stream package. Dave
