Add an experimental option to use libostree's "staging" API #1352
Conversation
|
My test case: |
|
Right now though that option isn't enabled by default...one thing I was thinking is to pick one or two of the tests and turn that option on by default or something? |
There was a problem hiding this comment.
Right now though that option isn't enabled by default...one thing I was thinking is to pick one or two of the tests and turn that option on by default or something?
Ahh I see; turning it on for all the tests won't work for those that check for /etc files etc... Hmm, though there can't be that many of those either.
Maybe let's start with upgrades, layering-basic, and layering-relayer?
src/daemon/rpm-ostreed.conf
Outdated
| @@ -5,3 +5,6 @@ | |||
| [Daemon] | |||
| #AutomaticUpdatePolicy=none | |||
| #IdleExitTimeout=60 | |||
|
|
|||
| #[Experimental] | |||
| #StageDeployments=false | |||
There was a problem hiding this comment.
Do we even want to have it commented out in the baked config? My initial thoughts were to keep it hidden, though I'm open to document it this way.
| gboolean is_staged = FALSE; | ||
| g_variant_dict_lookup (dict, "staged", "b", &is_staged); | ||
|
|
||
| if (opt_verbose && (is_staged || first)) |
There was a problem hiding this comment.
Hmm, let's drop the || first part? That way we can tell more easily if StageDeployments=true is active.
There was a problem hiding this comment.
I don't see how that'd help. For that we'd need to pass the boolean status from the daemon to the client, right?
The way the logic is now, if there is a pending deployment we'll always see whether or not it's staged, which was the main idea.
There was a problem hiding this comment.
Oh I see, right. I somehow read it as always printing yes. That makes sense.
Now that infrastructure for this has landed in libostree, let's make it easy for people to opt-in to testing it. This is a distinct first step for adding it as an update policy.
|
OK reworked this a bit and added a test that just does |
|
Just gave it a spin here and it's working nicely! One thing that took me by surprise was that |
|
⚡ Test exempted: merge already tested. |
Following up to coreos#1352 AKA 506910d which added an experimental flag to globally enable deployment staging, let's add an `ex-stage` automatic update policy. I chose to create a new `test-autoupdate-stage.sh` and rename the previous one to `test-autoupdate-check.sh` in going with the previous theme of smaller test files; it's way faster to iterate on new tests when it's a new file. And adding staging at the top would have been weird. This was all quite straightforward, just plumbing through lots of layers.
I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in coreos/rpm-ostree#1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable.
I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in coreos/rpm-ostree#1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable.
I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in coreos/rpm-ostree#1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable. Closes: #1583 Approved by: <try>
I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in coreos/rpm-ostree#1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable.
I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in coreos/rpm-ostree#1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable. Closes: #1583 Approved by: jlebon
Following up to coreos#1352 AKA 506910d which added an experimental flag to globally enable deployment staging, let's add an `ex-stage` automatic update policy. I chose to create a new `test-autoupdate-stage.sh` and rename the previous one to `test-autoupdate-check.sh` in going with the previous theme of smaller test files; it's way faster to iterate on new tests when it's a new file. And adding staging at the top would have been weird. This was all quite straightforward, just plumbing through lots of layers.
Following up to #1352 AKA 506910d which added an experimental flag to globally enable deployment staging, let's add an `ex-stage` automatic update policy. I chose to create a new `test-autoupdate-stage.sh` and rename the previous one to `test-autoupdate-check.sh` in going with the previous theme of smaller test files; it's way faster to iterate on new tests when it's a new file. And adding staging at the top would have been weird. This was all quite straightforward, just plumbing through lots of layers. Closes: #1321 Approved by: jlebon
Now that infrastructure for this has landed in libostree,
let's make it easy for people to opt-in to testing it. This is a distinct first
step for adding it as an update policy.