Jan Damborsky wrote: > 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.
Sure, I don't think I disagree with what you're saying here. In the normal cases, things naturally tend to move forward and the latest build/release is what's wanted. But I do also think that there are environments where a particular release, not necessarily the latest, is what's desired like redeploying a system that's part of a cluster or cloud where a particular release is needed. > >> >> 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 ? If things are known in advance, then we can obviously deploy X+1 bits with X+1 installers too. Cost benefit analysis comes into play when we're actually trying making a decision given known limitations and trade offs. I'm not even there yet. I'm merely trying to determine if the X-1 use case is a case that's worth entertaining. thanks, -ethan > >> >>> >>> >>>> >>>> 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 >
