On 01/21/10 01:00 PM, Dave Miner wrote: > 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?) ;-) I had not completely thought through the format. However my thought was that derived manifests would be a consumer.
-Sanjay > > Dave > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
