Dave Miner wrote: > 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. >
I hate replying to myself, but even more radically, based on the list of packages supplied, calculate the version of the installation environment required and assemble an installation zone on the fly from an IPS repository... Dave
