search

cilium / packer-ci-build

Contains the scripts and data for building the Cilium CI testing VM.
10 stars 17 forks source link

Upgrade to Ubuntu 22.04 and update tparse #366

Closed leblowl closed 1 year ago

leblowl commented 1 year ago

Hi,

I noticed the latest dev VM boxes (version 72 and 73) appear to be broken, due to an error in clang:

 runtime1: clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by clang)
    runtime1: clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by clang)
    runtime1: clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by clang)
    runtime1: clang: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by clang)
    runtime1: clang: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by clang)
    runtime1: clang: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by clang)

which I believe is due to the use of Ubuntu 20 in the dev boxes mismatching the environment clang is built in. I then found https://github.com/cilium/packer-ci-build/pull/358 and just applied a couple fixes to get it to build and satisfy review comments. I also noticed that the tparse installed in master doesn't include the -progress feature, so I updated that dependency. I tested the 4.19 and 5.4 images locally by running the cilium integration tests. Anyways, not sure if this is helpful or if ya'll are moving away from this infrastructure, but the docs still reference it https://docs.cilium.io/en/stable/contributing/development/dev_setup/ and perhaps this branch can unblock some folks who still want to use it.

aanm commented 1 year ago

/build

nbusseneau commented 1 year ago

/build

leblowl commented 1 year ago

It looks like there was a temporary commit that enabled the post processors on PR jobs, which caused a conflict when uploading to Vagrant Cloud because the PR jobs and Master jobs have overlapping build IDs and upload the same artifact, using build ID as the version. Other than the post processors in the net-next build, everything built successfully. I reverted that commit and the post processors haven't changed in this PR, so I think it should be good now.

nbusseneau commented 1 year ago

/build

leblowl commented 1 year ago

This PR also removes the Jenkinsfile for the 4.9 build, so I think that check should be disabled. I don't think I have the ability to do that though

aanm commented 1 year ago

@nbusseneau can we drop the build from Jenkins? I'll remove the "required" from the PR checks. I think we can merge this PR. Thank you for this @leblowl :clap:

Next the image will be officially build and then we can update them in cilium/cilium.

aanm commented 1 year ago

@leblowl I can't merge the PR. Do you mind rebasing against the latest tip of master?

nbusseneau commented 1 year ago

I don't think we should drop 4.9, considering it's still used by older stable branches (unless we move on from 4.9 to 4.19 for these as well like we did in 1.13, of course). We probably want to think about what we want to do going forward for the image maintenance considering only stable branches are still using the packer images.

leblowl commented 1 year ago

Ok, any preference on dropping 4.9 for older stable branches (i.e. moving them to 4.19)? If you'd like to keep it around a bit longer, I can work on getting a 4.9 image building.

aanm commented 1 year ago

@leblowl does the 4.9 need to be updated? I think we can leave it untouched and if we need it we can work on it afterwards.

leblowl commented 1 year ago

@aanm I think since all the images share the same clang install script, when running clang it'll produce glibc errors like above. But since the 4.9 image itself is only used for older release builds (and those builds are using an older version of the image that works), like you are saying, we could just leave it and fix it if needed. I can restore the 4.9 files and rebase.

aanm commented 1 year ago

@aanm I think since all the images share the same clang install script, when running clang it'll produce glibc errors like above. But since the 4.9 image itself is only used for older release builds (and those builds are using an older version of the image that works), like you are saying, we could just leave it and fix it if needed. I can restore the 4.9 files and rebase.

that LGTM, @nbusseneau all good?

leblowl commented 1 year ago

When I looked into it, the changes to upgrade the 4.9 image to Ubuntu 22.04 had already been done in previous commits. I just removed cgroup v2 support for the 4.9 image and it built successfully. I rebased on master. If you want to keep 4.9 on Ubuntu 20.04, I can do that too.

aanm commented 1 year ago

/build

nbusseneau commented 1 year ago

Yeah that's perfect thanks!