RFE: support pinning packages to specific versions during upgrade transactions

[miabbott]

It may be desirable for users/admins to prevent certain packages from being changed during upgrade transactions.

A use case that has recently come up is if a host has a specific version of a container runtime or kubelet, and they don't want their existing kubernetes cluster to break when those components are upgraded as part of the normal release cadence. However, they are still interested in the rest of the package set being upgraded.

Perhaps this is also applicable to other transactions, but upgrade was the first and most likely candidate, IMO.

[cgwalters]

We support this today, but it's only going to be reliable if the repo you're pulling the package from has history. That means not Fedora (or well, you can pin to the "gold" version but not an "updates" version). But it certainly works on e.g. CentOS AH for some packages...though now that I actually look history doesn't seem to be consistently maintained? But at least there's multiple buildah and koji packges in
extras.

# rpm-ostree status
State: idle
Deployments:
● ostree://centos-atomic-host:centos-atomic-host/7/x86_64/standard
                   Version: 7.1805 (2018-06-11 11:03:09)
                    Commit: 6275caab694c56515c57f5e5ef923d999e16e8fb1241992d155ff03cfb528261
              GPGSignature: Valid signature by 64E3E7558572B59A319452AAF17E745691BA8335
# rpm-ostree install koji-1.11.0-5.el7.centos.noarch
...
Will download: 3 packages (216.3 kB)                                              
 ...
Transaction complete; bootconfig swap: yes deployment count change: 1
Added:                                  
  koji-1.11.0-5.el7.centos.noarch                     
  libcomps-0.1.8-7.el7.x86_64                     
  pyOpenSSL-0.13.1-3.el7.x86_64               
  python-kerberos-1.1-15.el7.x86_64  
  python-krbV-1.0.90-8.el7.x86_64                                      
  python-requests-kerberos-0.7.0-2.el7.noarch
  python2-libcomps-0.1.8-7.el7.x86_64           
Run "systemctl reboot" to start a reboot                   
# rpm-ostree upgrade                                 
1 metadata, 0 content objects fetched; 313 B transferred in 0 seconds
Checking out tree 6275caa... done
Enabled rpm-md repositories: base updates extras
rpm-md repo 'base' (cached); generated: 2018-05-03 20:17:37
rpm-md repo 'updates' (cached); generated: 2018-07-17 16:08:36
rpm-md repo 'extras' (cached); generated: 2018-07-17 21:06:25
                                      
Importing metadata [=============] 100%
Resolving dependencies... done            
No upgrade available.                   
# rpm-ostree status
State: idle
Deployments:
  ostree://centos-atomic-host:centos-atomic-host/7/x86_64/standard
                   Version: 7.1805 (2018-06-11 11:03:09)
                BaseCommit: 6275caab694c56515c57f5e5ef923d999e16e8fb1241992d155ff03cfb528261
              GPGSignature: Valid signature by 64E3E7558572B59A319452AAF17E745691BA8335
           LayeredPackages: koji-1.11.0-5.el7.centos.noarch

● ostree://centos-atomic-host:centos-atomic-host/7/x86_64/standard
                   Version: 7.1805 (2018-06-11 11:03:09)
                    Commit: 6275caab694c56515c57f5e5ef923d999e16e8fb1241992d155ff03cfb528261
              GPGSignature: Valid signature by 64E3E7558572B59A319452AAF17E745691BA8335

Note the exact NEVRA in LayeredPackages; there's a koji-1.15.1-1.el7.centos.noarch.rpm that exists and would be installed with a plain rpm-ostree install koji.

[cgwalters]

So do you think there is something missing here?

[dustymabe]

I think for the kubelet case it would be nice if we could lock on a stream. i.e. we don't lock on a specific NVRA, but something a little higher level. I think modularity would give us this. In that case we can lock to kubernetes 1.9.x, so if 1.10.1 comes out we don't update, but if 1.9.2 comes out we do.

[cgwalters]

Right; such a thing doesn't exist in base librpm today, that's what modularity is doing.

(That said at large scale I think people will want consistency across their machines, which drives back towards having a higher level orchestrator pin these types of things, doing custom composes etc.)

[miabbott]

I understand users can do rpm-ostree install to a specific version for packages not included in the base deployment. Is the mechanism the same for packages that exist in the base deployment?

My imagined use case came out of that FCOS discussion we had, where FCOS would by default ship with a version of crio and kubelet that are intrinsically linked, for example version 1.11. In an unmanaged environment (i.e. user is rolling their own kubernetes cluster), the user wants to keep those versions installed after an upgrade...how would they do that? Is it just explicitly using rpm-ostree install to lock to the previously installed version ahead of the upgrade?

[dustymabe]

Is it just explicitly using rpm-ostree install to lock to the previously installed version ahead of the upgrade?

yes, i think so, or preemptively doing it right after install, which would lock you to an NVR.

The desired middle behavior is what I was describing above where people get incremental updates by default (follow 1.9.x), but not major updates. This middle ground behavior is something we believe modularity will give us once it's integrated into libdnf.

@cgwalters correct me if I'm wrong in my assumption here. It won't be zero work for us, but now we have a desired use of it I believe. Related: #1435