Evan Layton wrote: >>> >>> That is correct. So if I understand correctly, the requirement is to >>> support >>> both installation of older IPS bits as well as newer IPS bits >>> comparing to >>> the ones AI image was created from ? What is the need to support >>> installation >>> of older bits ? >> >> The same need as for supporting the installation of newer bits. >> What is it about installing newer bits that makes it more of a >> desired use case than the corollary? >> >> The general case I thought we are trying to solve is that if >> there is no technical reason why bld X should fail to install >> X-1 or X+1, why should it not be supported, or why should >> we prevent that? >> > > That implies that we will be maintaining some type of list or > database that defines all the versions we can and can't install for > a given boot image version/installer.
By choosing to support the forward case, aren't we implicitly maintaining half of what you're stating above? > I don't think this really gets > us what we want because we would have to also keep track of all the > differences between all these differnt versions and know exactly what > needs to be done to work around these differences. Would storing ICT with the installed bits solve this? > For example we > would have to know that if we have booted version C of the boot > image/installer and we are installing version A that for version A > we have to create the zpool using version 12 but for version B it > has to be version 13 and for version C the zpool has to be version > 14... This seems like a huge limitation and not something we would > want to get into. Isn't this what we're essentially going to be doing for the forward support case? i.e. regardless of what the booted version is, we must create a zpool based on the version of the bits being installed. This is true for both forward and backwards support. The difference though is that with the forward case, we can adjust/uprev the zpool version after instantiating the zpool, whereas with the backwards case, we need to determine what version to create upfront. If this is absolutely unattainable, then okay, we're blocked by the limitation. > Plus to make s the test matrix a bit unmanageable... It would make the test matrix 2x whatever it is to support the forward cases. > > The going forward examples are a bit more manageable in that things > like updating the zpool version can be done with a transient SMF > service or something like that. It seems we're generalizing the ease or difficulty between the forward case vs. backwards case based only on one particular source of the incompatibility - the zpool version. I'm not trying to argue that we have to support the backwards case. But if we choose not to, then I just want to be clear the reason why we're not. thanks, -ethan
