Giters

containers / common

Location for shared common files in github.com/containers repos.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[v0.53.x][git cherry-pick 5c81adc] apparmor: fix parsing beta/alpha version

hswong3i opened this issue · comments

commented

Similar as #1744, we need git cherry-pick 5c81adc via v0.53.x for CRI-O v1.27.x (see https://github.com/cri-o/cri-o/blob/release-1.27/go.mod#L23)

commented

@rhatdan could we have corresponding branch created for PR?

commented

@hswong3i we don't have a v0.53 branch. Can you bump up to v0.55? Or do we need to create a v0.53 branch? If it's going to a new v0.53 branch, I'm fine with that, as we don't use that in RHEL.

commented

I am giving a try for CRI-O branch main with cri-o/cri-o#7491, but seems will bump a lots of else dependencies. Since I am not the daily CRI-O maintainer it is not easy for me to understand how to making it works.

Moreover I am packaging CRI-O v1.26/1.27/1.28 with OBS daily, e.g. https://build.opensuse.org/package/show/home:alvistack/cri-o-cri-o-1.28.2. I could expect that bumping those legacy CRI-O dependencies to common's v0.55.x/0.57.0 could generate even much more troublesome...

But what we need is all about this simple single commit cherry-pick... So I am now applying the patch on-the-fly during packaging, e.g. alvistack/cri-o-cri-o@b162055

It works but a dirty workaround. Therefore if we could have some simple hotfix patch release for CRI-O legacy branch referencing, the solution could be much simpler and elegant?

commented

@TomSweeneyRedHat seems directly upgrade CRI-O dependency to v0.57.0 could not works, see cri-o/cri-o#7491 (comment)

Therefore individual patch release from common could be much suitable?

commented

I like to point out the actual issue here first. It seems cri-o is using "unsupported" versions of our libs and tools. And by "unsupported" I mean we generally only support the latest version so the answer should be update. We do have longer term supported branches but those are meant for RHEL and need to follow the RHEL process which means each backport needs to have a JIRA bug against the correct version and must be approved. This means we cannot just accept any backport.

Now I have no problem with creating branches for cri-o but the problem is that CI may no longer work on these branches as the old (unused) VM images could be deleted by now because normally such LTS branches must be created directly after the release to keep the CI running and prevent the images from being deleted. And if we have such branches then we should name them x.y.z-crio and they should be maintained by cri-o maintainers and should be created when they make a new release.
IMO this is work that should be done by cri-o folks and not us podman folks mainly because only they know what backports they actually need and want. I am happy to assist and setup people with repo permissions if needed. I know @saschagrunert has them so he should be able to create branches.

Also for us it would properly be better to use the -rhel suffix for our branches like we do in podman to keep in mind that they need the special RHEL process for backports and we cannot just merge anything.

commented

I can remember that I created release branches as-required in c/storage to fix bugs in CRI-O. I’d say we stick to that approach for the other libraries as well. CRI-O following Kubernetes releases with 1 year support means that they also have to support the used libraries for that time. Upgrading c/common can mean a lot of work as y’all know and I hope we can lower the efforts especially when the community works on long term support versions.

commented

Sounds like a good item for the next community meeting.
Cc: @TomSweeneyRedHat

commented

The Tuesday Dec 12 one?

commented

Good thought on discussing at the Cabal meeting on December 12. Agenda with conference link included here: https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both

commented

I give a temp fork branch for v0.53.0 + cherry-pick, see https://github.com/alvistack/containers-common/commits/alvistack/v0.53

So it should basically working for CRI-O release-1.27, see

commented

Hopefully we are just on time before 2023-12-12 Cabal meeting, with some positive feedback from CRI-O:

Quick summary:

  • CRI-O 1.29.x and main could benefit with cri-o/cri-o#7526, by referencing to github.com/containers/common v0.57.0
  • CRI-O 1.28.x could benefit with #1744, by referencing to github.com/containers/common v0.55.5-0.20231119144331-165b7a4dd43c
    • FOLLOW UP REQUIRED: As #1744 (comment) mentioned, we shall have a containers/common v0.55.x patch release for CRI-O referencing, but not pinning to specific GIT commit
  • CRI-O <= 1.27.x could benefit with my personal fork + patch on containers/common v0.52.x/v0.53.x, so CRI-O could reference to a specific forked GIT commit, passing with its updated CI pipelines
    • FOLLOW UP REQUIRED: We shouldn't let CRI-O pointing to my forked GIT commit, we shall create containers/common branches for v0.52.x/v0.53.x + patch releases
commented

follow up from the meeting: CRI-O admins will own branches in c/common to backport the pieces we need. I will work with the c/common admins to get access to the branches we need

commented

@hswong3i, we've recently incorporated your fixes into older CRI-O release branches. Everything appears to be in order.

Again, thank you so much for the bug report, the fix, the backports, etc. Much appreciated!

That said, I believe we can close this issue now as resolved.