-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add prune-ref flatpak-installer action #296
base: master
Are you sure you want to change the base?
Conversation
To try to avoid downloading the summary file when it already has the current version, the ostree client requests the summary and signature with an If-Modified-Since HTTP header (when it can't use the preferable If-None-Match header). The HTTP header only has second precision, so it may not receive an updated summary if the request is sent within the same second the summary is updated. To ensure the client will always receive the updated summary, sleep until the next second if necessary. Note that only the signature file is checked since it's always created after the summary. https://phabricator.endlessm.com/T32791
When trying to debug a failing test, it can be useful to see the HTTP requests and responses. Send the `ostree-trivial-httpd` logs to a file in the test temporary directory. https://phabricator.endlessm.com/T32791
Only a subdirectory of the temporary directory was being passed back to the caller, so nothing was cleaning it up. Instead, have the caller allocate the temporary directory and provide the path to perform the checkout in. Without this, `/tmp/ostree-checkout-*` directories were being left behind every time `eos-updater` entered the fetch state. https://phabricator.endlessm.com/T32791
The intention of the test is that 2 app install entries with different branches should not be compressed. The specified entries were installing 2 different apps instead of the same app with different branches. https://phabricator.endlessm.com/T32791
There have been some bugs where a Flatpak is uninstalled but the underlying OSTree ref is not removed. That means the commit objects won't be pruned and the host won't recover any disk space. This adds the `prune-ref` autoinstall action to remove those refs. This action only takes effect when the corresponding Flatpak is no longer installed. https://phabricator.endlessm.com/T32791
{ | ||
"properties": { | ||
"action": { | ||
"const": "prune-ref", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pwithnall would know better, but I am not sure that you can cleanly add new actions like this in a backwards-compatible way without an OS checkpoint. The actions from the OS update being deployed are parsed and prepared by the old eos-updater version.
I copied the example from the manpage to my local system, then did a dry run:
wjt@camille:~$ cat /var/lib/eos-application-tools/flatpak-autoinstall.d/99-prune-ref.json
[
{
"action": "prune-ref",
"branch": "stable",
"serial": 2017100300,
"ref-kind": "app",
"name": "org.example.UninstalledApp",
"collection-id": "org.example.Apps",
"remote": "example-apps"
}
]
wjt@camille:~$ /usr/libexec/eos-updater-flatpak-installer --dry-run --mode check
eos-updater-flatpak-installer-Message: 09:21:29.098: Running in mode ‘check’
(eos-updater-flatpak-installer:4989): libeos-updater-util-WARNING **: 09:21:29.099: Skipping the following actions while parsing ‘99-prune-ref.json’, due to not supporting their contents. They will not be reapplied later; the system may be in an inconsistent state from this point forward.
{"action":"prune-ref","branch":"stable","serial":2017100300,"ref-kind":"app","name":"org.example.UninstalledApp","collection-id":"org.example.Apps","remote":"example-apps"}
[...]
I then tried installing an OS update with this file still in place. To my surprise the OS update was deployed despite this warning:
Dec 15 09:23:12 camille eos-updater[1915]: Skipping the following actions while parsing ‘99-prune-ref.json’, due to not supporting their contents. They will not be reapplied later; the system may be in an inconsistent state from this point forward.
{"action":"prune-ref","branch":"stable","serial":2017100300,"ref-kind":"app","name":"org.example.UninstalledApp","collection-id":"org.example.Apps","remote":"example-apps"}
So it looks like I am wrong and in fact the action would be applied after booting into the new OS version which supports this feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might still be right (there's a big comment in the code about it), but this action isn't used in the pre-upgrade part by eos-updater since there's no fetching involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would need to thoroughly test whether an unrecognised action at the prepare phase would prevent:
- subsequent actions in the same file being prepared (I think yes)
- actions in subsequently-named files being prepared (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can’t remember what the code was meant to do (sorry), so defer to the big comment and (more importantly) testing of whether this actually works.
I broke out the unrelated fixes to #296 and will rebase if that's merged. |
g_message ("Remote name for %s is %s", collection_id, remote_name); | ||
} | ||
if (collection_id != NULL && | ||
!validate_collection_id_remote (installation, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: The branch would be a bit clearer if the validate_collection_id_remote()
function was split out in a preparatory commit. No point doing that now, though, since the review is underway :)
|
||
formatted_ref = flatpak_ref_format_ref (action->ref->ref); | ||
refspec = g_strdup_printf ("%s:%s", action->ref->remote, formatted_ref); | ||
if (!ostree_repo_resolve_rev_ext (repo, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be taking the collection ID into account too? Perhaps with ostree_repo_resolve_collection_ref()
?
existing_action_for_ref->type == EUU_FLATPAK_REMOTE_REF_ACTION_UPDATE) | ||
if (existing_action_for_ref == NULL || | ||
(ref_action_type_priority (action->type) >= | ||
ref_action_type_priority (existing_action_for_ref->type))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aiui this logic will squash [uninstall org.gnome.Foobar, prune-ref org.gnome.Foobar]
into just [uninstall org.gnome.Foobar]
, dropping the prune-ref. Is that what we want? Are we sure that uninstalls will now always prune?
@@ -1844,6 +1906,8 @@ find_related_refs_for_action (FlatpakInstallation *installation, | |||
if (!flatpak_transaction_add_update (transaction, ref_action_ref, NULL, NULL, error)) | |||
return FALSE; | |||
break; | |||
case EUU_FLATPAK_REMOTE_REF_ACTION_PRUNE_REF: | |||
break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest adding a short comment in here to make it clear this case isn’t accidentally unimplemented.
@@ -2671,3 +2744,64 @@ euu_flatpak_transaction_uninstall (FlatpakInstallation *installation, | |||
|
|||
return transaction_run_single_op (transaction, cancellable, error); | |||
} | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Double empty line should just be a single empty line
euu_flatpak_transaction_prune_ref (FlatpakInstallation *installation, | ||
const gchar *remote, | ||
const gchar *formatted_ref, | ||
gboolean no_prune, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could do with a brief comment (maybe formatted as a gtk-doc comment for the function) which explains what no_prune
means in the context of a function whose name suggests that the only thing it does is to prune.
EUU_FLATPAK_REMOTE_REF_ACTION_INSTALL); | ||
} | ||
|
||
/* Test that no compresson occurs if 'install' and 'prune-ref' are on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: ‘compression’
{ | ||
"properties": { | ||
"action": { | ||
"const": "prune-ref", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can’t remember what the code was meant to do (sorry), so defer to the big comment and (more importantly) testing of whether this actually works.
The purpose of this PR is to add an action for the flatpak installer to cleanup dangling OSTree refs for uninstalled Flatpaks. This is primarily for cleaning up from bugs here or in other software (the image builder).
The PR could be split up some if preferred. The first 4 commits are entirely independent things I came across when making tests. The last commit could be broken up by component. It also might need a couple more tests.
https://phabricator.endlessm.com/T32791