On 01/21/10 02:56 PM, Sanjay Nadkarni wrote: > On 01/21/10 09:59 AM, Dave Miner wrote: >> 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. > All true, except that the pool needs to be created before the image can > be laid down and hence I was planning on the image providing hints > about storage layout. >
That seems fine, especially if the hints were in the form of an AI manifest (fragment?) ;-) Dave
