Dave Miner wrote:
> Sarah Jelinek wrote:
> ...
>>
>> I was actually thinking we would run the ICT stuff before we did the 
>> pkg image-update. Much like we do a pkg image-update on a live system 
>> today. So, I assume ips would take care of the configuration changes 
>> that are required during an image update.
>>
>> The process would be:
>> 1. Install the bits that match the current booted client.
>> 2. The normal ICT and post install stuff is run by AI.
>> 3. Then run pkg image-update if we have detected that the user asked 
>> for later bits than the booted client version.
>>
>> Do you think this would work?
>>
>
> I'm sure it would work, since it's exactly the path you'd follow in 
> updating from version R(unning) to version I(nstalled).  But I 
> question whether it's necessary...

Our thinking was that instead of worrying about updating the installer 
bits to handle the mismatch in version, and potentially introducing an 
incompatibility between the installer and the kernel, we would be able 
to do this to get the user the build/release they wanted in case the 
booted client was an older build than the bits the user wanted to install.

Instead of maintaining a versioning mechanism to try to decide what we 
can or cannot install, we could do it this way and insure we keep things 
consistent for the user. We would have to figure out if the 
build/release they wanted to install is different than the build that 
the client booted with.

thanks,
sarah
***
>
>> As for upgrading the zpool version if we detected there was a version 
>> higher that could be supported.. I think this is required since the 
>> user is expecting to get the latest version supported with their 
>> request. We can manage this in a fairly straightforward way I think.
>>
>
> I think updating zpool versions is a fairly minor issue, not one I'd 
> focus on.  The only problem it causes is newer features that aren't 
> available until the upgrade, but that isn't an entirely unexpected 
> path, since if you've been doing updates, you'll have the same 
> problem, and hence there'll be documentation and so on covering the 
> issue.
>
> Dave
>


Reply via email to