Ubuntu jammy and noble (22.04 LTS and 24.04 LTS)
#1843
Conversation
|
Jenkins, test this please |
1 similar comment
|
Jenkins, test this please |
There was a problem hiding this comment.
Reviewable status: 0 of 17 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @woju)
a discussion (no related file):
I'm putting a blocking comment to not accidentally merge this PR (before the full cycle of validation is done, also from the Intel internal CI side). This PR will surely go in only after Gramine v1.7.
There was a problem hiding this comment.
Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "WIP" found in commit messages' one-liners (waiting on @dimakuv)
a discussion (no related file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
I'm putting a blocking comment to not accidentally merge this PR (before the full cycle of validation is done, also from the Intel internal CI side). This PR will surely go in only after Gramine v1.7.
It should be the other way around: we shouldn't release 1.7 without merging this PR. The PR (if ready), should get merged exactly on 25.04. (noble release). If we'll release v1.7 after 25.04, then we'll be bound by this project's policy to support 24.04 and 22.04, irrespective of Intel's internal CI and validation.
There was a problem hiding this comment.
Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "WIP" found in commit messages' one-liners (waiting on @woju)
a discussion (no related file):
If we'll release v1.7 after 25.04, then we'll be bound by this project's policy to support 24.04 and 22.04, irrespective of Intel's internal CI and validation.
I'm confused by this sentence. Why would merging this PR exactly on 25.04 change anything? This PR is about adding 22.04 and 24.04, so why can't this PR be merged after 25.04?
There was a problem hiding this comment.
Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv)
a discussion (no related file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
If we'll release v1.7 after 25.04, then we'll be bound by this project's policy to support 24.04 and 22.04, irrespective of Intel's internal CI and validation.
I'm confused by this sentence. Why would merging this PR exactly on 25.04 change anything? This PR is about adding 22.04 and 24.04, so why can't this PR be merged after 25.04?
Because Ubuntu 24.04 LTS is expected to be released on 25.04.2024: https://launchpad.net/ubuntu/noble, so we target the exact date. If we release 1.7 before 25.04.2024, the we're technically not bound to support noble until 1.8, but if we release 1.7 after 25.04.2024, then we release with noble support, so it would be unwise to release without passing CI.
There was a problem hiding this comment.
Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @woju)
a discussion (no related file):
Previously, woju (Wojtek Porczyk) wrote…
Because Ubuntu 24.04 LTS is expected to be released on 25.04.2024: https://launchpad.net/ubuntu/noble, so we target the exact date. If we release 1.7 before 25.04.2024, the we're technically not bound to support noble until 1.8, but if we release 1.7 after 25.04.2024, then we release with
noblesupport, so it would be unwise to release without passing CI.
Yes, all these things I understand. What I find confusing is your statement that this PR must be merged exactly on 25.04. Why merging this PR after 25.04 will be a problem?
There was a problem hiding this comment.
Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv)
a discussion (no related file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Yes, all these things I understand. What I find confusing is your statement that this PR must be merged exactly on 25.04. Why merging this PR after 25.04 will be a problem?
I guess it will not be a problem if we do the actual merge slightly after 25.04., but before subsequent release (1.7 or 1.8, whichever it will be). In any case, we need to be ready for merging exactly 25.04, to be ready e.g. for scenario in which we release 1.7 on 26.04.
woju
force-pushed
the
woju/ubuntu-noble
branch
12 times, most recently
from
f87c7c5
to
7e2d16f
Compare
There was a problem hiding this comment.
Reviewable status: 0 of 22 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv and @woju)
a discussion (no related file):
Woju as part of the PR you seem to be renaming/removing Ubuntu20.04 but as per Ubuntu (https://wiki.ubuntu.com/Releases) , 20.04 is supported at least till April 2025. So why are we removing support for Ubuntu 20.04?
There was a problem hiding this comment.
Reviewable status: 0 of 22 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv and @jinengandhi-intel)
a discussion (no related file):
20.04 is supported at least till April 2025
By Canonical, not by us.
See https://gramine.readthedocs.io/en/latest/devel/packaging.html#packaging-and-distributing. This has always been our policy.
There was a problem hiding this comment.
Reviewable status: 0 of 22 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv, @jinengandhi-intel, and @woju)
a discussion (no related file):
Depends on #1865 ([glibc] Adjust CFLAGS should be dropped from here after merging that PR).
There was a problem hiding this comment.
Reviewable status: 0 of 22 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv and @woju)
a discussion (no related file):
Previously, mkow (Michał Kowalczyk) wrote…
20.04 is supported at least till April 2025
By Canonical, not by us.
See https://gramine.readthedocs.io/en/latest/devel/packaging.html#packaging-and-distributing. This has always been our policy.
Why do we still have 18.04 then in Ubuntu supported distros?
There was a problem hiding this comment.
Reviewable status: 0 of 22 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL), "DO NOT MERGE" and "WIP" found in commit messages' one-liners (waiting on @dimakuv and @woju)
a discussion (no related file):
Previously, jinengandhi-intel wrote…
Why do we still have
18.04then in Ubuntu supported distros?
We just forgot to update the list there, it's not supported since long time ago (as the previous sentence there indicates).
@woju: could you update packaging.rst in this PR, to only list 22.04 and 24.04?
There was a problem hiding this comment.
Reviewable status: 0 of 28 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: ITL) (waiting on @dimakuv, @jinengandhi-intel, and @mkow)
a discussion (no related file):
Previously, mkow (Michał Kowalczyk) wrote…
We just forgot to update the list there, it's not supported since long time ago (as the previous sentence there indicates).
@woju: could you update packaging.rst in this PR, to only list 22.04 and 24.04?
By all means.
a discussion (no related file):
Previously, mkow (Michał Kowalczyk) wrote…
Depends on #1865 (
[glibc] Adjust CFLAGSshould be dropped from here after merging that PR).
I've rebased on master and dropped the patch.
|
Jenkins, test Jenkins-SGX-24.04 please |
There was a problem hiding this comment.
Reviewed 1 of 1 files at r9, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @mkow)
.ci/ubuntu24.04.dockerfile line 9 at r9 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
Oh, and this is CI, not anything that we support for users. FWIW users who don't want to use
manticrepos can recompile those libraries themselves.
Ok, I'm unblocking this. I added a note in our roadmap here on GitHub, that if PSW/DCAP packages are not yet released for 24.04 at the time we release Gramine v1.8, we'll need to put a note/warning in our Release Notes. I think this is a fair compromise.
There was a problem hiding this comment.
Reviewed 3 of 5 files at r7, 4 of 5 files at r8, 1 of 1 files at r9, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @woju)
a discussion (no related file):
Previously, woju (Wojtek Porczyk) wrote…
Done.
@woju: Please update the description of the PR accordingly, so it's not confusing for the people reading the merge log later.
You can always switch reviewable to review commit by commit.
I can't, only the first reviewer can decide about that.
Even more annoying is waiting for review in this project
It would have gone much faster if you had split it into smaller PRs, because reviewing most of them would be trivial and we could have merged them right away (also, they wouldn't be blocked on discussions about other changes).
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
'python3-voluptuous' # dependencies for various tests, CI-Examples, etc.
Why is this list so different from 24.04? Aren't we running all these tests on both?
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
So eventually I just pass seccomp argument to
docker().inside(). Rationale is that it depends onnode()specifier, so I think it's fair to have it variable per-node.
Ok, but the original issue still stands - docker_seccomp.json is not tested anymore.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @mkow)
a discussion (no related file):
Previously, mkow (Michał Kowalczyk) wrote…
@woju: Please update the description of the PR accordingly, so it's not confusing for the people reading the merge log later.
Done.
Previously, mkow (Michał Kowalczyk) wrote…
You can always switch reviewable to review commit by commit.
I can't, only the first reviewer can decide about that.
Even more annoying is waiting for review in this project
It would have gone much faster if you had split it into smaller PRs, because reviewing most of them would be trivial and we could have merged them right away (also, they wouldn't be blocked on discussions about other changes).
Something like new distro versions cannot be done in single commit, because things change all over the place, and you can't test end result when they aren't all merged. So it would look like a train of PRs stacked one on top of another, and to test it you'd need to rebase all subsequent PRs, which would be nightmare. You just need to review stuff, this PR was hanging for a month already.
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Why is this list so different from 24.04? Aren't we running all these tests on both?
Not yet. Right now I wanted to merge at least something, and more tests will be switched sometime later.
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Ok, but the original issue still stands -
docker_seccomp.jsonis not tested anymore.
No, it's tested in linux-direct-ubuntu20.04-gcc-debug.jenkinsfile, linux-direct-ubuntu20.04-gcc-release.jenkinsfile and linux-direct-sanitizers.jenkinsfile, just referenced by real path, not by symlink.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @woju)
-- commits line 32 at r6:
Most of these commits were simple and would be merged right away.
You just need to review stuff, this PR was hanging for a month already.
Most of that time was spent waiting on the decision and discussion about what to do about 20.04 (which the original version of this PR was removing). And during review your response times were similar to mine.
Anyways, my point is that in that time we could have merged all these small commits and only the stuff requiring discussions would have to wait (and would be easier to review). We do that with all other features and it really makes reviewing and merging easier.
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
Not yet. Right now I wanted to merge at least something, and more tests will be switched sometime later.
What's wrong with the other tests? Was there any discussion about that anywhere?
This seems like a dangerous thing to do, we could have merged this and forget that some tests aren't running in CI anymore.
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
No, it's tested in
linux-direct-ubuntu20.04-gcc-debug.jenkinsfile,linux-direct-ubuntu20.04-gcc-release.jenkinsfileandlinux-direct-sanitizers.jenkinsfile, just referenced by real path, not by symlink.
Ah, it's a symlink. Quite confusing.
It points to an outdated policy, shouldn't we update it? If I see correctly, it's only referenced to by GSC's index.rst, right?
There was a problem hiding this comment.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @woju)
Previously, mkow (Michał Kowalczyk) wrote…
Most of these commits were simple and would be merged right away.
You just need to review stuff, this PR was hanging for a month already.
Most of that time was spent waiting on the decision and discussion about what to do about 20.04 (which the original version of this PR was removing). And during review your response times were similar to mine.
Anyways, my point is that in that time we could have merged all these small commits and only the stuff requiring discussions would have to wait (and would be easier to review). We do that with all other features and it really makes reviewing and merging easier.
Also, this PR still contains commits which are either unrelated or should be separate PRs - [Docs] Update supported Ubuntu versions (this should be a separate PR, merged after all the 24.04 work is done), [CI] Rewrite ubuntu22.04.dockerfile for consistency is just some refactoring, [CI] Don't clone linux-sgx-driver on builds against upstream driver is only a clean-up / perf improvement unrelated to 24.04.
Not sure about the others, maybe it's even more.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @mkow)
Previously, mkow (Michał Kowalczyk) wrote…
Also, this PR still contains commits which are either unrelated or should be separate PRs -
[Docs] Update supported Ubuntu versions(this should be a separate PR, merged after all the 24.04 work is done),[CI] Rewrite ubuntu22.04.dockerfile for consistencyis just some refactoring,[CI] Don't clone linux-sgx-driver on builds against upstream driveris only a clean-up / perf improvement unrelated to 24.04.
Not sure about the others, maybe it's even more.
"rewrite 22.04" was requested in review, "update supported versions" we merge together, because usually we merge related stuff (docs and tests) together, and "don't clone linux-sgx-driver" is performance optimisation (not cleanup), because we don't need it with upstream driver. Previously it was needed for all CI pipelines apart from the VM one.
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
What's wrong with the other tests? Was there any discussion about that anywhere?
This seems like a dangerous thing to do, we could have merged this and forget that some tests aren't running in CI anymore.
I didn't want to start fixing them all, hoping in vain that this quick PR will be merged soon and I'll be able to start fixing tests.
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Ah, it's a symlink. Quite confusing.
It points to an outdated policy, shouldn't we update it? If I see correctly, it's only referenced to by GSC's index.rst, right?
I think it's liable just to be removed once we deprecate 20.04.
Yes, non-qualified is not described in this repo, we documented those with dates (see the bottom of installation.rst).
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv, @kailun-qin, and @woju)
Previously, woju (Wojtek Porczyk) wrote…
"rewrite 22.04" was requested in review, "update supported versions" we merge together, because usually we merge related stuff (docs and tests) together, and "don't clone linux-sgx-driver" is performance optimisation (not cleanup), because we don't need it with upstream driver. Previously it was needed for all CI pipelines apart from the VM one.
I still don't see why they are here. Usually when someone requests unrelated changes which are big enough for their own commit then we do them, but in a separate PR.
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
I didn't want to start fixing them all, hoping in vain that this quick PR will be merged soon and I'll be able to start fixing tests.
Are they actually broken on 24.04 or you didn't try yet?
@kailun-qin, @dimakuv: Should we merge a partial pipeline, or fix these tests first? If the former, we need to create an issue to not forget that some tests are silently skipped on 24.04.
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
I think it's liable just to be removed once we deprecate 20.04.
Yes, non-qualified is not described in this repo, we documented those with dates (see the bottom of
installation.rst).
Hmm, does this mean that GSC in direct mode cannot run on 24.04 currently? (because it will use the old seccomp policy)
Anyways, I agree, we should do this when dropping 20.04.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv, @kailun-qin, and @mkow)
Previously, mkow (Michał Kowalczyk) wrote…
I still don't see why they are here. Usually when someone requests unrelated changes which are big enough for their own commit then we do them, but in a separate PR.
I think I explained why they are in this PR. Is there anything actionable for me in this thread?
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Are they actually broken on 24.04 or you didn't try yet?
@kailun-qin, @dimakuv: Should we merge a partial pipeline, or fix these tests first? If the former, we need to create an issue to not forget that some tests are silently skipped on 24.04.
Haven't tried yet.
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Hmm, does this mean that GSC in direct mode cannot run on 24.04 currently? (because it will use the old seccomp policy)
Anyways, I agree, we should do this when dropping 20.04.
The policy needs to be specified by the user every time, so it's up to the user to specify that newer one anyway. It's only referenced in documentation, not in the code itself.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv, @kailun-qin, and @woju)
Previously, woju (Wojtek Porczyk) wrote…
I think I explained why they are in this PR. Is there anything actionable for me in this thread?
No, only for me (see the initial message in this thread).
There was a problem hiding this comment.
Reviewed 1 of 19 files at r1, 2 of 3 files at r3, 1 of 5 files at r5, 3 of 22 files at r6, 2 of 5 files at r7, 4 of 5 files at r8, 1 of 1 files at r9, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv and @woju)
.ci/linux-direct-ubuntu20.04-gcc-debug.jenkinsfile line 8 at r9 (raw file):
"local:${env.BUILD_TAG}", '-f .ci/ubuntu20.04.dockerfile .' ).inside("${env.DOCKER_ARGS_COMMON} --security-opt seccomp=${env.WORKSPACE}/scripts/docker_seccomp_mar_2021.json") {
A bit off the topic, just wondering any special reason that we did not point to the seccomp profile for newer docker versions (docker_seccomp_aug_2022)?
Code quote:
docker_seccomp_mar_2021.json
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Should we merge a partial pipeline, or fix these tests first?
I prefer the latter but I'm fine w/ the former + an issue (if it makes @woju easier).
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv)
.ci/linux-direct-ubuntu20.04-gcc-debug.jenkinsfile line 8 at r9 (raw file):
Previously, kailun-qin (Kailun Qin) wrote…
A bit off the topic, just wondering any special reason that we did not point to the seccomp profile for newer docker versions (docker_seccomp_aug_2022)?
I don't fully understand the question. Is it "why we won't use newer (2022) seccomp for older machines"? If so, then we can't use it, because it contains references to not-yet-existing syscalls (as of the kernel that is running on the machine and/or docker runner itself). The first one that is breaking is clone3 I think, that's what the error says, but I'm not sure if there aren't more.
If I wanted to do that, I'd need to dist-upgrade all the existing machines at once, and that would be problematic, because some of those don't have FLC, and it would break SGX on them. On those with FLC the newer kernel would have upstream driver, so I'd have to also update CI to -Dsgx_driver=upstream (it's oot at the moment), so it would quickly become a major operation, which I don't think it's in scope of this PR. I want to do it by migrating those machines into VMs one by one, and those two new pipelines do run in VMs (node("sgx")), but all existing (node("sgx_slave_2.6" and node("nonsgx_slave")) are bare metal.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @mkow and @woju)
.ci/linux-direct-ubuntu20.04-gcc-debug.jenkinsfile line 8 at r9 (raw file):
Is it "why we won't use newer (2022) seccomp for older machines"? If so, then we can't use it, because it contains references to not-yet-existing syscalls (as of the kernel that is running on the machine and/or docker runner itself).
Yes, that's what @kailun-qin meant by his question.
From my side, I confirm what @woju says -- some of our CI machines have a too-old host Linux kernel, so they can't use a newer seccomp policy because it contains unknown-to-host-Linux syscalls.
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
Why is this list so different from 24.04? Aren't we running all these tests on both?
@mkow Did you mean "why so different from 20.04"? As @woju explained, most of the tests are run under 20.04 currently, and only some tests run under 22.04.
I didn't see a big problem with having this partial pipeline as is in this PR, as the "forget about some tests" would be visible in the "Remove 20.04 pipeline" follow-up PR. But I'm fine with creating a small GitHub issue.
Created the issue: #1893
.ci/lib/config-docker.jenkinsfile line 6 at r6 (raw file):
Hmm, does this mean that GSC in direct mode cannot run on 24.04 currently? (because it will use the old seccomp policy)
As @woju explained, GSC doesn't restrict or hard-code the seccomp policy at all. GSC doesn't even participate in this, as the user simply runs classic docker run ..., not anything GSC-wrapped. See documentation: https://gramine.readthedocs.io/projects/gsc/en/latest/#execute-with-linux-pal-gramine-direct
There was a problem hiding this comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dimakuv, @kailun-qin, and @woju)
.ci/ubuntu22.04.dockerfile line 36 at r9 (raw file):
as the "forget about some tests" would be visible in the "Remove 20.04 pipeline" follow-up PR
How would that be visible? You'd just see the old pipeline files removed, and that's all?
Created the issue: #1893
Same as Kailun, I'd prefer if all the tests were fixed first, but I won't block on this if there's an issue created to remember about it.
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
Signed-off-by: Wojtek Porczyk <[email protected]>
There was a problem hiding this comment.
Reviewable status:
complete! all files reviewed, all discussions resolved
There was a problem hiding this comment.
Reviewable status:
Description of the changes
noblewas released on 25.04.2024. From Gramine 1.8 we'll supportnobleandjammyso it's about time to have those in CI.How to test this PR?
check CI
This change is