Ethan Quach wrote: > > > Jan Damborsky wrote: >> Ethan Quach wrote: >>> >>> >>> Jan Damborsky wrote: >>>> Hi Ethan, >>>> >>>> >>>> Ethan Quach wrote: >>>> >>>>> >>>>> 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? >> >> I think those use cases are not quite equal. This comes from >> IPS repository versioning scheme - it is unidirectional - >> when anything is pushed into IPS repo, version is always >> changed to newer, never to older one. >> >> Speaking about particular use case, let's assume that at some >> point user has AI image which allows installation of IPS bits >> currently available in given IPS repos. >> >> When time runs, it is likely that newer bits will be made >> available, it can't happen that older bits occur in IPS repo. >> So only X+1 versioning problem will occur. > > It sounds like what you're referring to is when the install > configuration points to an IPS repo with no branch > specification. In that case, we have a configuration that > points to a moving target, and yes in that case, since the default > branch in IPS repos only move forward, that would seem > like the logical flow to follow.
With respect to this, I am more trying to think how the deployment model might look like in production environment. Let's assume that I am in position of administrator deploying Solaris Next version 1 on my systems. Then when time flows and new systems are to be installed or existing ones to be reinstalled, I think it is more likely that 'patched' or 'more recent' version is to be chosen, not the older one. > > But, the fact that an install configuration can point to a > moving target is a minor implementation detail of a separate > module. What we determine here to be our desired use cases for > the installer to support has nothing to do with how an IPS > repo progresses IMO. > >> >> I am not sure, how common is going to be comparing to the others >> when X-1 problem would have to be solved, just trying to think >> where the differences come from and how those map to the possible >> use cases. > > Repos can have multiple builds, and if a user wanted to install a > particular build, a manifest would be customized to install particular > buildN. Reuse of this 'known to work manifest' would be the use case > I can think of where we could be in a situation that a buildX > installer is > told to install buildX-1 The question here might be if the information about what versions will be deployed is known in advance (then the installer+manifest format chosen might be based on the oldest version to be installed) or if this requirement is discovered later. Then what would be the cost to create manifest for installerX-1 and use installer X-1 for installing X-1 bits versus supporting installation of older bits ? > >> >> >>> >>> 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? >> >> I think those two cases are not symmetric with respect >> to the limitations of technologies AI consumes: >> >> * IPS supports only upgrade >> * ZFS pool allows only upgrade >> >> I am not sure if there are any technical limitations for >> them (there might be), but at least we need to take them >> into account when thinking what is involved in support of X-1. >> >>> >>>> >>>>> >>>>> 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. >> >> Is it something which has to be handled by Snap Upgrade >> or can it be addressed by IPS ? > > Updating grub on the disk was considered out of scope for the > image-update process. image-update updates the contents of the > image within some boot environment. The boot environment subsystem > is then told to 'activate', or make that boot environment boot on next > reboot. Ensuring that grub is up to date for that boot environment was > considered a responsibility for that step. I see - thanks for clarifying this ! Jan
