William Schumann wrote: > Evan, > Evan Layton wrote: >> William Schumann wrote: >>> Evan, >>> Among proposed features in the AI client "redesign" is the ability to >>> reuse an existing ZFS root pool without having to specify the virtual >>> device location. In this scenario, existing BEs might be retained, >>> and ZFS datasets in the root pool but outside the BEs might also be >>> retained. There has been no feedback about the usefulness of this >>> proposed feature as yet, but if an existing ZFS root pool were used, >>> this would be another versioning case to consider. >>> William >> >> I don't think this is really a separate versioning issue but is more >> something that should be added to the zpool version checking. If we >> find that there is an existing pool we need to get it's zpool version >> and check that against the bits we want to install to make sure that >> they are capable of using that pool. > Yes, we can do that with the root pool or any other ZFS pools. This > would be a Target Discovery enhancement - according to the installer > architecture, it would be done in a ZFS pool discovery module, so Target > Discovery might also be mentioned in the spec. >> What I'm not sure of with this issue is, if this pool version check >> fails, should fail the install at that point or put an install on a >> pool that we know it can't use. If the pool version is newer than the >> bits we're installing can support I would say that we should fail at >> this point because we know it won't work. >> > Also proposed as an follow-on feature in the AI client "redesign" is the > ability to specify that a ZFS upgrade be performed on a ZFS pool. In > the manifest, pools could be tagged for upgrades as needed, or an option > to upgrade all pools could be provided. > Concerning whether to fail the install if ZFS pools fail the version > check, it may be preferable to complete the install, with log warnings > and instructions on using zpool(1m) to upgrade. > William
Right for the case where the zpool version we find is older that what the bits being installed understands the pool can definitely be upgraded. It's also a very good idea to log this information and also let the user know on the console that the zpool needs to be upgraded. However if there are already existing BE's on that pool updating the zpool version could make them unuseable so I'm not sure we would want to auto matically upgrade the pool. The other issue that I was referring to as far as failing the install is if the pool we find has a version that is newer than the bits being installed could understand. In this case there is no way the the installed bits could ever be booted since they could not understand that pool version. Due to this I was thinking that we may want to fail the install because we know that the pool version is not compatible with the bits to be installed. -evan >> I'll add this to the zpool checking part of the spec. >> >> Thanks! >> -evan >> >>> >>> Evan Layton wrote: >>>> The functional spec for Install Versioning (version compatibility) >>>> is posted at: >>>> >>>> http://opensolaris.org/os/project/caiman/CVERS/CVERS-FUNC/ >>>> >>>> Your comments and feedback would be appreciated. >>>> >>>> Thanks! >>>> -evan >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
