Evan Layton wrote: > Jan Damborsky wrote: >> Hi Ethan, >> >> >> Ethan Quach wrote: >>> >>>> 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 ? > > We're talking about the IPS version, partially as least. The problem > is that the OS version (possibly based on the IPS bits) that the > clients boots to needs to match the OS version (and IPS bits) we are > installing. This is all on the client. In this context the version > could be something like the version of the entrie package (but I'm not > sure that will work either) or the build number of Solaris.
We are likely touching the implementation details here, but I think clarifying this might affect the design. In general, what I am trying to understand is if there is a way to implement what's captured in functional spec and how the established versioning scheme will affect number of AI images somebody will have to maintain - how it will scale. One thing we might need take into account is the release model which is going to replace current patching technology - how it is going to work with respect to versioning and 'backporting' bug fixes into appropriate IPS repos which could cause 'incompatibility' issues. > >> >>> >>>> >>>> >>>>> 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 ? > > I don't think installing older bits that what the client has currently > booted is a requirement. In fact I don't think that is something we > want to support going forward. Older bits would have to be installed > while booted from those same bits (or older?). That was my understanding as well. > >> >>> >>> 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 ? > > There are also possibilities with things like the boot sector. An > example of this was when installboot was intorduced with new boot for > SPARC. In this instance it is required that installboot from the newly > installed bits have to be run. If the OS we've booted doesn't match > what we've installed there is a possibility that installbott could > fail and we would not be able to boot the newly installed OS. If kernel incompatibility prevents installboot invoked from alternate root to do its job correctly, I agree this is the issue, since we can't do the right thing during the first boot as boot process itself is affected. That said, shouldn't be some transition mechanism made available by team in charge, as 'pkg image-update' and thus upgrade process is affected by this issue as well ? Thank you, Jan
