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. 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 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. -ethan > > I am asking trying to understand what the pieces are installer > really has to take care of and what can be solved by other > mechanisms/projects. > > Thank you, > Jan >
