Sarah Jelinek wrote: > 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. >
I don't think you'd do it every time, but only in case of a mismatch. The common case is to roll out matched sets. > 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. > My concern about splitting it otherwise is that zones represent a well-understood system architecture boundary, whereas the split you suggest above doesn't feel so easy to define (or maintain). Either way, I think we're talking about an advanced solution to a relatively uncommon problem in most environments, so I don't know that I'd invent lots of special architecture for it, but if there's a fairly straightforward solution that leverages existing architecture, then it becomes more interesting to go ahead and solve. Dave
