Ethan Quach wrote: > > > Jan Damborsky wrote: >> Hi Ethan, >> >> >> Ethan Quach wrote: >>> >>> >>> Jan Damborsky wrote: >>>> Hi Evan, >>>> >>>> >>>> Evan Layton wrote: >>>>> Hi Folks, >>>>> >>>>> We are in need of your input on requirements for the version >>>>> compatibility work. >>>>> >>>>> Some draft examples of requirements that we're looking at are: >>>>> * Define the versions of the installations we will support >>>>> o 1 to 1 match for live CD and pkg based installs. >>>> >>>> Just to clarify, by LiveCD installs, you mean using cpio transfer >>>> mechanism ? >>>> >>>> As far as pkg based installs are concerned, how 1:1 match >>>> requirement maps >>>> to the existing IPS versioning scheme ? Will it be always assured >>>> that this >>>> information can be derived from AI manifest ? >>> >>> With what we currently have in the manifest, it is impossible to >>> assure this >>> by inspecting the manifest. We would need to *require* that the specific >>> build be in given in the manifest, not just the repo and branch. >> >> ok. >> >>> >>>> How 1:1 match requirement will affect scalability with respect to >>>> number of AI images >>>> administrator will have to maintain ? >>> >>> Not sure what you're asking here. Are you thinking of a particular >>> implementation? In general, I don't think the CVERS problem is >>> going to be solved on the server. To keep the client modular, its >>> got to be able to validate whatever its given at run time anyway. >> >> Sorry about the confusion - I probably I misunderstood 1 to 1 match >> requirement >> mentioned in the requirement list above. I assumed that it means that >> IPS version of bits to be installed has to be the same as IPS version >> AI image >> was created from. But it seems that 'version' word relates to version >> mechanism >> established by CVERS project - is it correct ? >> What establishes CVERS version - how is it determined - what are the >> inputs to >> define it ? >> >>> >>>> >>>> >>>>> o possible mismatch for image based installs such as >>>>> replicated images. >>>>> * Define the behavior when a mismatch is detected >>>>> o which do we handle and which do we flag as an error. >>>> >>>> When IPS transfer mechanism is used for the installation, I am >>>> thinking if >>>> there might be possibility to get rid of this problem or move it to >>>> the more >>>> explored area by using similar IPS mechanism we have on running >>>> system when >>>> we do the updates. >>>> >>>> For now IPS fresh install is one step process - just 'pkg install' >>>> packages >>>> listed in AI manifest of the version specified in AI manifest. >>>> >>>> The another approach might be to do the fresh install as two step >>>> process: >>>> >>>> [1] install the system with the same version as booted AI image and >>>> do the all >>>> post install config stuff. >>>> [2] If version specified in AI manifest is newer, use 'pkg >>>> image-update' >>>> mechanism to update the installed bits to the required version. >>>> >>>> Not sure, if this approach is viable, but it seems that the >>>> incompatibility >>>> problem would move to the area being used and explored. >>>> >>>> There are issues we would need to check with IPS team, but before >>>> starting >>>> that more detailed discussion, I am wondering, if it is even worth to >>>> consider that approach. >>> >>> It doesn't seem to solve the problem for when an older build is wanted. >>> i.e. you can't image-update backwards. >> >> 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. 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. 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. Plus to make s the test matrix a bit unmanageable... 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. -evan >> >>> >>> In general, using IPS's pkg ideology to ensure the contents of the IMAGE >>> is intact is a good idea. So moving any and all, if possible, of our >>> ICTs >>> into pkg contents is what we are driving towards. But their are >>> structural >>> pieces outside of the IMAGE -- disk, zpool, grub, etc -- that pkg >>> doesn't >>> touch and we still need to consider those in the CVERS problem. >> >> I am currently aware of need to manually run 'zpool upgrade' in order >> to 'upgrade' ZFS pool to the latest version, do we happen to know if >> there are >> other incompatibilities pkg 'image-update' currently doesn't take care >> of and >> how they are handled ? > > The one we know of is updating grub on the disk. We currently > handle this be pushing that responsibility to the be_activate() > code. > > > thanks, > -ethan > >> >> Thank you, >> Jan >>
