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.
-Sanjay > > Dave
