after pinning single deployment all future deployments are pinned #1595
Labels
Comments
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
May 22, 2018
With the new support for pinning deployments, we need to also update rpm-ostree to clean up the transient state as is now done in the ostree sysroot upgrader. This addresses that issue as well as tries to be a little cleaner in how we clean up other transient state. Notably, we add a new helper function to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In other cases, we do want this transient information since it allows us to describe the deployment. Closes: ostreedev/ostree#1595
|
Ahh OK, so this is indeed an rpm-ostree issue. We just never taught rpm-ostree to drop the transient keys like ostree learned in #1464. I'm fine just leaving it here though -- I opened coreos/rpm-ostree#1372. |
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
May 22, 2018
With the new support for pinning deployments, we need to also update rpm-ostree to clean up the transient state as is now done in the ostree sysroot upgrader. This addresses that issue as well as tries to be a little cleaner in how we clean up other transient state. Notably, we add a new helper function to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In other cases, we do want this transient information since it allows us to describe the deployment. Closes: ostreedev/ostree#1595
|
This is an rpm-ostree bug, AFAIK the raw ostree bits work. Let's track it via the PR jlebon opened. When I was implementing this I had only tested with ostree unfortunately. |
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
May 23, 2018
With the new support for pinning deployments, we need to also update rpm-ostree to clean up the transient state as is now done in the ostree sysroot upgrader. This addresses that issue as well as tries to be a little cleaner in how we clean up other transient state. Notably, we add a new helper function to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In other cases, we do want this transient information since it allows us to describe the deployment. Closes: ostreedev/ostree#1595
rh-atomic-bot
pushed a commit
to coreos/rpm-ostree
that referenced
this issue
May 23, 2018
With the new support for pinning deployments, we need to also update rpm-ostree to clean up the transient state as is now done in the ostree sysroot upgrader. This addresses that issue as well as tries to be a little cleaner in how we clean up other transient state. Notably, we add a new helper function to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In other cases, we do want this transient information since it allows us to describe the deployment. Closes: ostreedev/ostree#1595 Closes: #1372 Approved by: cgwalters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After pinning single deployment all future deployments are pinned.
versions:
ostree-2018.5-1.fc28.x86_64rpm-ostree-2018.5-1.fc28.x86_64I started at f28 atomic
I pinned that deployment:
I rebased to updates ref and rebooted:
Note both deployments say they are pinned. I then rebase to testing ref and reboot:
I then deployed one more commit (the previous ref in the testing stream) so we could get one more deployment:
I guess the problem is related to the fact that I only pinned one deployment but all of them are pinned. Is that expected behavior?
I actually like this feature (i.e. pin everything for me), but I don't think this is what someone would expect and would possibly lead to disk space issues.
The text was updated successfully, but these errors were encountered: