upgrade --preview yields unexpected information in ostree log

[dustymabe]

Basically ostree log will then output information about the commit that was previewed and the existing commit that the system is currently deployed to will not be in there.

-bash-4.3# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/docker-host
       Version: 25.46 (2017-01-24 02:48:29)
        Commit: 27b1ae24686697235c35b793b5c8ab0822b8427e892d3659f0cb300c400979fa
        OSName: fedora-atomic
-bash-4.3# 
-bash-4.3# 
-bash-4.3# rpm -q rpm-ostree 
rpm-ostree-2016.13-1.fc25.x86_64
-bash-4.3# 
-bash-4.3# ostree log fedora-atomic/25/x86_64/docker-host                                                                                                                                                                                   
commit 27b1ae24686697235c35b793b5c8ab0822b8427e892d3659f0cb300c400979fa
Date:  2017-01-24 02:48:29 +0000
Version: 25.46
(no subject)

<< History beyond this commit not fetched >>
-bash-4.3# 
-bash-4.3# rpm-ostree upgrade --preview                                                                                                                                                                                                     
Updating from: fedora-atomic:fedora-atomic/25/x86_64/docker-host

7 metadata, 19 content objects fetched; 7118 KiB transferred in 6 seconds                                                                                                                                                                   
!atomic-1.14.1-1.fc25-x86_64
=atomic-1.15.1-1.fc25-x86_64
!gomtree-0-0.2.git8c6b32c.fc25-x86_64
=gomtree-0.3.0-1.fc25-x86_64
!gssproxy-0.5.1-3.fc25-x86_64
=gssproxy-0.6.1-2.fc25-x86_64
!kernel-4.9.5-200.fc25-x86_64
=kernel-4.9.6-200.fc25-x86_64
!kernel-core-4.9.5-200.fc25-x86_64
=kernel-core-4.9.6-200.fc25-x86_64
!kernel-modules-4.9.5-200.fc25-x86_64
=kernel-modules-4.9.6-200.fc25-x86_64
!libidn2-0.11-1.fc25-x86_64
=libidn2-0.16-1.fc25-x86_64
!libpsl-0.14.0-2.fc25-x86_64
=libpsl-0.17.0-1.fc25-x86_64
!net-tools-2.0-0.38.20160329git.fc25-x86_64
=net-tools-2.0-0.40.20160329git.fc25-x86_64
!nfs-utils-1:1.3.4-1.rc3.fc25-x86_64
=nfs-utils-1:2.1.1-1.fc25-x86_64
!ostree-2016.15-1.fc25.1-x86_64
=ostree-2017.1-2.fc25-x86_64
!ostree-grub2-2016.15-1.fc25.1-x86_64
=ostree-grub2-2017.1-2.fc25-x86_64
+publicsuffix-list-dafsa-20170116-1.fc25-noarch
!python3-crypto-2.6.1-11.fc25-x86_64
=python3-crypto-2.6.1-13.fc25-x86_64
!vim-minimal-2:8.0.206-1.fc25-x86_64
=vim-minimal-2:8.0.238-1.fc25-x86_64
-bash-4.3# 
-bash-4.3# rpm-ostree status                                                                                                                                                                                                                
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/docker-host
       Version: 25.46 (2017-01-24 02:48:29)
        Commit: 27b1ae24686697235c35b793b5c8ab0822b8427e892d3659f0cb300c400979fa
        OSName: fedora-atomic
-bash-4.3# 
-bash-4.3# 
-bash-4.3# ostree log fedora-atomic/25/x86_64/docker-host
commit be109ecf1dcb3c5e352a2afc124b50a36ced19973be2f06df52bcc835489d2df
Date:  2017-01-31 06:36:48 +0000
Version: 25.52
(no subject)

<< History beyond this commit not fetched >>
-bash-4.3#

Could we enhance ostree log to output information about both? Ideally there would be a user friendly way to have all of the log, even for commits that aren't local and just on the remote.

[mbarnes]

IIUC, the main objection of the bug is less about presence of the new commit from the upgrade --preview, but the absence of the previous deployed commit in the log. Correct?

Going through the same steps myself, I'm seeing both commits (previewed and deployed) in the ostree log. That part may have already been fixed since this issue was filed. Can you confirm?

I also found @cgwalters' commit message here helpful in explaining why a "preview" operation would leave behind evidence in the ostree log and rpm-ostree status output. (Initially I felt this was an inappropriate side-effect.)

[dustymabe]

IIUC, the main objection of the bug is less about presence of the new commit from the upgrade --preview, but the absence of the previous deployed commit in the log. Correct?

Mainly. It's kind of like doing a git fetch and then git log
pointing to a commit that your HEAD isn't at, and also not showing
any other commits (including the currently deployed one) because
History beyond this commit not fetched. The History beyond this commit not fetched issue could possibly be taken care of by #558

Going through the same steps myself, I'm seeing both commits (previewed and deployed) in the ostree log. That part may have already been fixed since this issue was filed. Can you confirm?

I re-did this on f25. See the 'details' section at the bottom of this
post.

I also found @cgwalters' commit message here helpful in explaining why a "preview" operation would leave behind evidence in the ostree log and rpm-ostree status output. (Initially I felt this was an inappropriate side-effect.)

I agree that deployments vs refs/commits are confusing. Maybe if we
make a deployment more like your 'working tree' in git and HEAD points
to the current deployment. The PendingCommit stuff can also be
confusing: #732

``` [root@vanilla-f25atomic ~]# rpm-ostree status State: idle Deployments: ● fedora-atomic:fedora-atomic/25/x86_64/docker-host Version: 25.148 (2017-06-25 21:07:13) Commit: f136ff5370c0f77d9c1f4fd3ecb8e1815650d8aaf834e41a5e995a13494407e9 [root@vanilla-f25atomic ~]# ostree log fedora-atomic/25/x86_64/docker-host commit f136ff5370c0f77d9c1f4fd3ecb8e1815650d8aaf834e41a5e995a13494407e9 Date: 2017-06-25 21:07:13 +0000 Version: 25.148 (no subject)

<< History beyond this commit not fetched >>
[root@vanilla-f25atomic ~]# rpm-ostree upgrade --preview
Updating from: (null)

4 delta parts, 4 loose fetched; 151052 KiB transferred in 15 seconds
!dbus-1:1.11.12-1.fc25-x86_64
=dbus-1:1.11.14-1.fc25-x86_64
!dbus-libs-1:1.11.12-1.fc25-x86_64
=dbus-libs-1:1.11.14-1.fc25-x86_64
!hostname-3.15-7.fc24-x86_64
=hostname-3.15-8.fc25-x86_64
!kernel-4.11.6-201.fc25-x86_64
=kernel-4.11.8-200.fc25-x86_64
!kernel-core-4.11.6-201.fc25-x86_64
=kernel-core-4.11.8-200.fc25-x86_64
!kernel-modules-4.11.6-201.fc25-x86_64
=kernel-modules-4.11.8-200.fc25-x86_64
!libgcrypt-1.6.6-1.fc25-x86_64
=libgcrypt-1.7.8-1.fc25-x86_64
!nfs-utils-1:2.1.1-5.rc3.fc25-x86_64
=nfs-utils-1:2.1.1-5.rc4.fc25-x86_64
!rsync-3.1.2-3.fc25-x86_64
=rsync-3.1.2-4.fc25-x86_64
!skopeo-0.1.19-1.dev.git0224d8c.fc25-x86_64
=skopeo-0.1.22-1.git5d24b67.fc25-x86_64
!skopeo-containers-0.1.19-1.dev.git0224d8c.fc25-x86_64
=skopeo-containers-0.1.22-1.git5d24b67.fc25-x86_64
!systemd-231-15.fc25-x86_64
=systemd-231-17.fc25-x86_64
!systemd-container-231-15.fc25-x86_64
=systemd-container-231-17.fc25-x86_64
!systemd-libs-231-15.fc25-x86_64
=systemd-libs-231-17.fc25-x86_64
!systemd-pam-231-15.fc25-x86_64
=systemd-pam-231-17.fc25-x86_64
!systemd-udev-231-15.fc25-x86_64
=systemd-udev-231-17.fc25-x86_64
!vim-minimal-2:8.0.642-1.fc25-x86_64
=vim-minimal-2:8.0.679-1.fc25-x86_64
[root@vanilla-f25atomic ~]#
[root@vanilla-f25atomic ~]# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.148 (2017-06-25 21:07:13)
Commit: f136ff5370c0f77d9c1f4fd3ecb8e1815650d8aaf834e41a5e995a13494407e9
PendingCommit: ce555fa89da934e6eef23764fb40e8333234b8b60b6f688222247c958e5ebd5b
PendingVersion: 25.154 (2017-07-04 01:38:10)
[root@vanilla-f25atomic ~]#
[root@vanilla-f25atomic ~]# ostree log fedora-atomic/25/x86_64/docker-host
commit ce555fa89da934e6eef23764fb40e8333234b8b60b6f688222247c958e5ebd5b
Date: 2017-07-04 01:38:10 +0000
Version: 25.154
(no subject)

<< History beyond this commit not fetched >>

[mbarnes]

I re-did this on f25. See the 'details' section at the bottom of this post.

Huh, okay. I guess this is because it's jumping ahead by several commits (25.148 -> 25.154), leaving a gap in the local chain of commits?

[dustymabe]

Huh, okay. I guess this is because it's jumping ahead by several commits (25.148 -> 25.154), leaving a gap in the local chain of commits?

right, i believe that is the case.