Dave Miner wrote: > 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...
I can see how this would work for our /usr and other filesystems we need read/write on the booted client to install the installer in to. The initial minimal zone size is ~140MB. Then we have to add the pkgs we need to get the zone populated with what we need. This could take a bit of time, zone creation, pkg installation...and I am wondering if the client performance would become an issue if we did this. Another thought I had is that we create a new mountpoint, /usr/install, or something like that, where our 'installer' bits get installed on the client. This allows us to not mess with the current /usr read only architecture, and we can mount this so that it is in tmpfs and install in to this space. We don't have ramdisk issues to contend with as a result. This would require us to modify package(s) and live-fs-root to know the new location. My concern about zones is that it feels like it is a heavy weight solution to maybe what isn't a heavyweight problem. Analysis needs to be done to understand what files and pkgs comprise the 'installer' in this scenario. thanks, sarah **** > > Dave >
