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? > >> >> 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 >
