-
Notifications
You must be signed in to change notification settings - Fork 86
Drop tinygo requirement #148
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
Conversation
|
Lines 27 to 29 in 82c65a7
You need to use Note that |
Yes, thank you now it works when vendoring the NRI into CRI-O. 👍 |
06afcd6 to
44c6377
Compare
|
@knqyf263 CI is green now, do we want to cut a new go-plugin release first? |
go.mod
Outdated
| module github.com/containerd/nri | ||
|
|
||
| go 1.22.0 | ||
| go 1.24.1 |
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.
We need to be a bit careful with this and check if this is (already) fine (at this point) for both for containerd/main and containerd/release/2.0. Ideally also for 1.7.x, but I'd say updating that anyway might require rolling a maintenance branch with hand-picked cherry-picks and we probably don't need/want to push WASM support for 1.7.x anyway.
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.
containerd/main seems to be on 1.23 right now, but CI is partially using go 1.24.
Proposing the new golang version in containerd/containerd#11533
@klihub this will also be a breaking change, WASM plugins compiled with tinygo will not work with golang ones because the underlying library changed. I still think it's worth it, having native golang support is brilliant.
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.
@saschagrunert I agree that using the stock/native golang toolchain is clearly preferable over depending on both golang and tinygo. I'm not too worried about the breaking WASM plugin runtime backward compatibility (if you guys are not). We only have had it in one tagged release, and we're not at 1.0.0 yet.
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.
but this is forcing everyone importing this library to move to 1.24, no?
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.
but this is forcing everyone importing this library to move to 1.24, no?
Yes.
We could think about wrapping a // +build go1.24 tag, but this would make a feature dependent on a certain golang version. It would also require more boilerplate.
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.
nod, and the MUST be go 1.24.1 in the go.mod file is forcing everyone that includes this to be dependent on 1.24.1 or higher. This change by golang to make the go tag a MUST is crashing all backwards compatibility testing across the board. Typically you chase it down and someone thought it cool to use a new log feature just introduced.
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.
I see, I was more asking about if was a deliberate change or an oversight, it looks is the only way, I didn;t mean to push in one or other direction
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.
updating that anyway might require rolling a maintenance branch with hand-picked cherry-picks and we probably don't need/want to push WASM support for 1.7.x anyway.
➕ I don't think we should take this for 1.7
this will also be a breaking change, WASM plugins compiled with tinygo will not work with golang ones because the underlying library changed
[...]
Proposing the new golang version in containerd/containerd#11533
Oof. So for containerd, either we:
- Require 1.24 in 2.1 (which can make it hard for distros to ship 2.1, delaying adoption), or
- Don't take 1.24 in 2.1 and ship 2.1 with the initial tinygo-based WASM support, and then immediately break that in the next release (2.2)
- Disable WASM in 2.1 and take the 1.24 minimum version change in 2.2 (which will be more reasonable timing-wise as Go 1.23 will have reached EOL)
None of those sound like great choices to me. I think option 2 sounds the worst though.
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.
Per the community call today, we are not going to upgrade containerd 2.1 to Go 1.24. This leaves us with either option (2) or (3) above.
My preference as-is would be option 3, disabling WASM support entirely until we have moved to Go 1.24 (which will happen for containerd 2.2). Unless there is some way to have the new WASM support sans-tinygo support old tinygo-based plugins?
|
@saschagrunert Thanks for testing it out. I'll cut a new release. |
|
@saschagrunert Is this something that would be important to get behind an NRI tag, so we could pull it in on the CRI-O side ? If it is, then maybe one alternative would be to branch off a 0.9 release branch and merge this there, but keep if off main until all parties involved/affected are content with moving to go 1.24 as the minimum version. |
I think that's a valuable solution, yes. We will move to go 1.24 in the future in any case. A build tag will not work with the go module requirements if I think about it, because go modules are not tag aware. Means we need the go 1.24 requirement independently of any build constraints. |
|
@klihub do you have a new base branch where I could rebase on? |
No, sorry, not yet. |
|
I think this can be rebased on |
a71d198 to
a2a4812
Compare
|
@saschagrunert Now we could rebase this and try to get it merged. I tried to do that, but I was hasty with my push (to your original source branch, argh... sorry 🙈) and now I can't figure out what I screwed up compared to your saved original branch, or if it is something extra that the additions since the base branch of that tree would require, since the WASM plugin compiles in your original but not in the updated version. |
@saschagrunert I think I managed to figure it out now... will update with a fixed branch. |
5af355a to
0af3a71
Compare
|
@klihub thank you! |
mikebrow
left a comment
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.
The matrix for go still includes 1.23.9 but during the setup for that version in switches to 1.24.3 instead.. thus we end up using 1.24.3 twice in CI..
Prepare all required actions
Getting action download info
Download immutable action package 'actions/setup-go@v5'
Run ./.github/actions/install-go
Run actions/setup-go@v5
Setup go version spec 1.23.9
Found in cache @ /opt/hostedtoolcache/go/1.23.9/x64
Added go to the path
Successfully set up Go version 1.23.9
go: downloading go1.24.3 (linux/amd64)
go version go1.24.3 linux/amd64
nit because this can be said for all the plugins.. TODO: need some readme docs for the WASM implementation... linking to https://github.com/knqyf263/go-plugin docs if nec..; explanation of special pkg/api; something for the plugin; and a test would be nice.
I removed that version from the matrix.
Yeah I can follow-up on docs and tests. |
Signed-off-by: Sascha Grunert <sgrunert@redhat.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com> Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
mikebrow
left a comment
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.
LGTM
Fixes #140