Evan Layton wrote: > Ethan Quach wrote: >> >> >> Sarah Jelinek wrote: >>> 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. >>>> >>>>> 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. >>>> >>>>> >>>>> >>>>>> 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. >>>> >>> Hi Ethan, >>> >>> I think that trying to solve the going backward problem isn't >>> something we should do. I believe that we need to exclude this case >>> from our requirements. >> >> Did I miss a memo :-) You and Jan seem to be on the same >> page here, but I haven't heard the reason why we should >> exclude support for this case. > > I thought we had been saying this all along. One example of this is > with the zpool version. If the boot image supports version 14 but the > older bits will only support up to version 12 we end up with an > install that can't boot if the zpool version is created using the > booted image.
Known limitations shouldn't dictate what we say we *want* to support. It may end up dictating what we end up *having* if there is no way around that limitation, but that is different statement. > >> >>> >>>> 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. >>>> >>>> >>> It is true that we don't have control of everything outside of the >>> image. It seems that the versioning mechanism would help us to >>> manage that. For example, if we detected a zpool version mismatch >>> between our booted kernel and what we are installing, we could >>> create an SMF enhanced profile that would reset the version of the >>> zpool correctly on first reboot. >> >> When you say "reset" you mean uprev right? I guess for >> completeness and predictability we could do that, but I don't >> know if that's crucially necessary since later zfs bits can run >> on older version pools okay. > > Right but without the expected functionality expected for the bits > we've installed. This unexpected result that is one of the issues > we're attempting to resolve and one of the things that we had > identified as a requirement. (expected results...) Ok. > >> >>> >>> I believe the intent is for us to use SMF to do configuration at >>> first reboot, correct? Are there things you envision that we could >>> 'correct' with this mechanism + "pkg image-update' on the alt root? >> >> Doing the 'pkg image-update' on the installed altroot wasn't >> my idea, and I'm actually trying work through what it buys us. >> I guess if we embed ICT with the installed bits, then doing >> the initial install from the same bld repo causes us to run ICT >> of the known supported matched bits. Then the image update >> brings us to the final desired build. >> >> ..hmm, it would seem like this process is still subject to whatever >> incompatibilities the current -- beadm+pkg image-update -- process >> on any running system is subject to. > > Yes it would be subgect to those same issues so I'm not sure this buys > us anything. Plus it doesn't appear to solve some of the issues that > we could solve with a transient SMF service that runs on first boot. What do you envision this transient SMF service that runs on first boot doing? -ethan > >> >> >> thanks, >> -ethan >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
