-
Notifications
You must be signed in to change notification settings - Fork 195
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
Turn staged deployments on by default #1430
Conversation
I haven't hit any issues either and haven't heard of anyone else hitting issues. So I'm +1 for enabling it next release! |
OK, looks like various things are going to need fixes, for example Some interesting questions here - the |
could we possibly enable this in rawhide for a month before we enable by default? |
Sure, would just need some fairly trivial build-time machinery here ( |
Hmm, OK yeah just hit the |
So, apart from #1434, it seems like all the other failures are either pure test adaptations or due to |
Yep - to make sure I understand, you want to fix staged+rollback before the release? That's fine by me. I definitely think we need to get the release out in order to smoke out the Rust bits and make sure that all works (before we do more of it). |
self->ex_stage_deployments = g_key_file_get_boolean (config, EXPERIMENTAL_CONFIG_GROUP, | ||
"StageDeployments", NULL); | ||
/* The default used to be `false`, so check for the key being present */ | ||
if (g_key_file_has_key (config, EXPERIMENTAL_CONFIG_GROUP, "StageDeployments", NULL)) |
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.
Maybe just one release with that, and then we drop support for the key entirely? Or were you thinking of keeping around support for StageDeployments=false
? I'm leaning more towards just not supporting turning it off.
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.
Yeah, agree.
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.
In this PR there's a build-time option; @dustymabe was arguing that this should go into rawhide first or something. I dunno if that's really worth it. We have FAHC for automated testing before release.
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.
yeah preferably it would go to rawhide/f29 first.. especially since we have silverblue, IoT, and FAH to consider.
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.
No strong opinions either way. Seems relatively low risk at this point, but I'm fine with delaying f28 for one more release or so. (Maybe at the same time we drop support for the StageDeployments
option completely),
OK, so the I could imagine chaging That said, really we want to enhance libostree here to support this, there's no real blockers other than dealing with the complexity in |
b809f35
to
ecb1d27
Compare
ecb1d27
to
3fcaed8
Compare
This is getting closer, split out two prep patches: |
3fcaed8
to
e047039
Compare
3f2fe91
to
fc55736
Compare
ba3da8f
to
6488058
Compare
bot, retest this please |
The thing confusing me is that the tests pass locally; that's why I hadn't made the change to the deployment count check. |
a46f4a8
to
b5f9830
Compare
OK, I figured it out - the |
Nothing calls it today; looks like it was last used in 283b915
So it's easier to debug. This inlines the helper into the only function that uses it.
Staging fixes the `/etc` bug for livefs. There's actually more we could do here around taking advantage of staging for livefs; for example, I think once the livefs is complete, we could just delete the staged deployment. And then we don't need to render on the next boot the live status, etc. Anyways, all that can come in the future. This is prep for enabling staging by default.
We've put a lot of work into staged deployments, it's time to pull the trigger and turn them on by default. This is a key step for enabling `stage` mode automatic updates by default in e.g. Fedora CoreOS/Silverblue. We add a new `--disable-staged` build-time option to flip things back.
b5f9830
to
aa26b20
Compare
Updated commit message, lifting WIP. Let's do this! |
@@ -29,9 +29,9 @@ set -x | |||
# This test suite enables the libostree staging feature, and executes | |||
# the layering-relayer tests. |
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.
Seems like these comments should be updated now for s/enables/disables
?
self->ex_stage_deployments = g_key_file_get_boolean (config, EXPERIMENTAL_CONFIG_GROUP, | ||
"StageDeployments", NULL); | ||
/* The default used to be `false`, so check for the key being present */ | ||
if (g_key_file_has_key (config, EXPERIMENTAL_CONFIG_GROUP, "StageDeployments", NULL)) |
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.
No strong opinions either way. Seems relatively low risk at this point, but I'm fine with delaying f28 for one more release or so. (Maybe at the same time we drop support for the StageDeployments
option completely),
Minor comment nit, though not worth a respin. Let's go! |
⚡ Test exempted: pull fully rebased and already tested. |
So it's easier to debug. This inlines the helper into the only function that uses it. Closes: #1430 Approved by: jlebon
Staging fixes the `/etc` bug for livefs. There's actually more we could do here around taking advantage of staging for livefs; for example, I think once the livefs is complete, we could just delete the staged deployment. And then we don't need to render on the next boot the live status, etc. Anyways, all that can come in the future. This is prep for enabling staging by default. Closes: #1430 Approved by: jlebon
We've put a lot of work into staged deployments, it's time to pull the trigger and turn them on by default. This is a key step for enabling `stage` mode automatic updates by default in e.g. Fedora CoreOS/Silverblue. We add a new `--disable-staged` build-time option to flip things back. Closes: #1430 Approved by: jlebon
Let's use this PR to track turning it on by default. I'd like to
do that after the next release. So far, everything seems fine.