Ethan Quach wrote: > > > 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?
Well one of those things might be updating the zpool version to that expected for the installed bits. I'm not sure of all the things that might be needed but this could be one solution to the issues around installing newer bits than what was running from the boot image. > > > -ethan > >> >>> >>> >>> thanks, >>> -ethan >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
