Sarah Jelinek wrote: > Dave Miner wrote: >> Evan Layton wrote: >>> Dave Miner wrote: >>>> Evan Layton wrote: >>>>> Problem statement: >>>>> >>>>> 1) A method is needed to match the OS version the AI server is >>>>> running on with >>>>> the OS version being installed. >>>> >>>> As Ethan noted, you mean "client" here. >>> >>> Yes that's correct. It probably should have be something more like >>> "the OS version being installed on the client". >>> >>>> >>>>> Note: There is currently information being logged which shows >>>>> this but it's not used for anything. >>>>> 2) A method of determining which OS version can support installions of >>>>> which OS versions is needed. >>>>> 3) This is something that the user should not have to keep track of >>>>> and should be maintained internally. Should incompatibilities be >>>>> documented so that users can at least look up why we're telling >>>>> them >>>>> that they have incompatible OS versions? >>>>> >>>> >>>> I think the part that's missing here is providing means to limit the >>>> incompatibility set. For example, installing an updated version of >>>> pkg into the installation environment once booted, or other software >>>> that we might need. >>> >>> OK so this is an additional requirement that all the needed packages >>> and their proper versions are installed on the client. In other words >>> all the correct packages corresponding to the version of the "entire" >>> package are installed on the client? >>> >> >> I don't think that's quite what I'm suggesting. I'm suggesting that >> the client be capable of dynamically adapting itself to run the >> versions of executables required to correctly install a particular >> version of the software. > > This seems like a good overall goal to have, but my concerns about this > are that the executables required might not be limited enough in scope > to be able to effectively do this. I would think we would need to have > an understanding of how many versions we would be willing to be 'off' or > what/how many executables would need to change to make this work. > > Just allowing an 'open' dynamic updating of the client seems too > unpredictable. >
I agree there are challenges, but IPS solves at least some of the problems for us. One kind of "out there" idea I've had rattling around in my mind is packaging the automated installer environment as a zone and using the update-on-attach capability. >> >>>> >>>> Also, let's not forget that it's not just AI that we might want to >>>> do this with; the various interactive installers are likely to grow >>>> options (such as installing from a repository) which make this an >>>> issue for them, too. >>> >>> Right, Ethan also mentioned that this should really say "package >>> based installs" not AI. >>> >> >> I think limiting it to package-based is still too narrow, in that the >> completion operations associated with an image-based installation >> would seem to have similar issues. I realize that you can't >> necessarily design a solution for something that's not yet specified, >> but think it should be examined as far as we can right now to >> hopefully make the solution applicable for both. >> > I have been thinking about this in regard to the replication and > recovery project. The way I have been thinking about this is: > > -When we create a 'copy' of a system we create a bootable iso that > contains(at a very high level): > > -An 'archive' of that system. > -The installer that will be used to 'install/re-install' the archive > on to systems. > > -This implies, to me, that the iso is self contained and that the > versioning issues wouldn't be possible as with a booted client and a > repository installation. The installer would manage the post install > completion operations. > > Of course, there is a fair amount of hand waving going on here with > regard to how we build the iso and the installer that is included on the > iso. I think that the versioning issues that Evan is working on still > apply at some level. In that I need to be able to figure out what > version the system being 'copied' is running, so that I can correctly > create the iso and installer to handle that version. > > If we allow for an OpenSolaris system 'archive' to be installed from > another mechanism besides the created iso(that is we only create the > 'copy' of the system not the iso, then yes, the versioning issues apply > with regard to the booted client and the archive we are trying to > 'install'. In particular if we use zfs send/receive or we allow for > 'incremental' copying of a system(even if zfs send/receive isn't used). > It is my thought that the iso would be something that can be bootable > both local and over a net, and capable of handling multiple installs of > systems at at time. > I think the thing to keep in mind is that there'll be a need to reconcile system minimization with the replication functions. So while I think bundled installer + contents is good for the general case, your design should account for the possibility of them being separated so that an isolated, minimized system could still be made into a replication image. Dave
