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.
OK I think I understand what you're saying here. As an example: if we're installing an older version on a client than what is on the server where the zpool versions differ we would need to dynamically determine the correct zpool version for the root pool on the client and create that version. > >>> >>> 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. Very true we'll attempt to keep these other types of installs in mind as well while looking at this. Karen mentioned this as well "Should it just be "package based installs"? Or should it be even more general to include installs where the bits to install is not bundled together with the installer? Eg: the installer could be installing from some sort of archive that sits in the network somewhere." Clearly, like has been mentioned, just stating package based installs (or AI) is too limiting in what we should be thinking about. Thanks for the clarifications! :-) -evan
