Skip to content
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

ostree-sysroot-deploy: check if deployments are in the same stateroot. #3234

Merged
merged 1 commit into from May 4, 2024

Conversation

jmarrero
Copy link
Member

@jmarrero jmarrero commented Apr 30, 2024

Our code currently does not check for stateroot as a differentiator between deployments, however given that we allow multiple stateroots, we should see them as different deployments in the same way we check for kargs for example.

Copy link

openshift-ci bot commented Apr 30, 2024

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

Copy link
Collaborator

@ericcurtin ericcurtin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this, but I am curious what is the use case where all the previous checks have not returned FALSE already. The case where this happens in real-life... We can't depend on changing kargs, this is correct, we use ostree=true in our Android Bootloader images for example.

@jmarrero
Copy link
Member Author

jmarrero commented May 1, 2024

thanks for the review!
Single Node Openshift uses stateroots for managing faster upgrades. And they hit this.

See OCPBUGS-30276

just trying to confirm locally this works as intended before moving this out of draft.

Copy link
Member

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh, good catch. Fun bug. I am actually looking forward to us trying to reuse the stateroot stuff more broadly as it's a very powerful thing.

I think it'd be relatively straightforward to do a test case for this in tests/admin-test.sh or so, I can help with that

src/libostree/ostree-sysroot-deploy.c Outdated Show resolved Hide resolved
@cgwalters
Copy link
Member

FWIW I'm also OK adding and shipping this without an additional test, since this looks like a relatively critical bug for that use case and I am very confident the fix is correct.

@jmarrero jmarrero force-pushed the state-root branch 2 times, most recently from f5dcef3 to a8e5235 Compare May 2, 2024 00:05
@jmarrero jmarrero marked this pull request as ready for review May 2, 2024 00:08
@jmarrero
Copy link
Member Author

jmarrero commented May 2, 2024

I can see the failure reported in the original issue with the test when I remove my changes:

error: Reloading deployments after commit: loading sysroot: Parsing deployment /ostree/boot.0/testos2/7bd091ad6955c0e7ef41bab65adb016275664b55efc0d10a0c8cb263da3c1e4e/0 in stateroot 'testos2': readlinkat: No such file or directory

@jmarrero jmarrero requested a review from cgwalters May 2, 2024 00:13
@cgwalters
Copy link
Member

[2024-05-02T00:14:50.093Z] FAIL: tests/test-libarchive-import 11 /libarchive/selinux - OSTree:ERROR:tests/test-libarchive-import.c:681:test_libarchive_selinux: assertion failed (error == NULL): Child process exited with code 1 (g-spawn-exit-error-quark, 1)

Hmm that one is weird.

@cgwalters
Copy link
Member

@jmarrero I think this just needs a rebase 🏄

@jmarrero jmarrero enabled auto-merge May 3, 2024 23:59
@jmarrero jmarrero merged commit f911d40 into ostreedev:main May 4, 2024
25 checks passed
@jmarrero jmarrero deleted the state-root branch May 4, 2024 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants