Discussion: nerdctl roadmap?

[apostasie]

Hey good folks.

If I have not seen you yet in 2025, wishing you all a happy new year, and all the best to you and your loved ones!

I got involved in nerdctl back in spring last year - very egoistically motivated by the fact some bugs were in my way. And I don't like bugs. Or things in my way.

Eventually, because the people here are so nice and straightforward, I stuck around and started sharing what was on my private fork.
Pretty much everybody I interacted with was awesome, but I would like to specially thank @djdongjin @fahedouch and @AkihiroSuda who suffered the brunt of my contributions and had to review obnoxiously large PRs.

Although my fork has now diverged significantly and is pursuing objectives that are not aligned with nerdctl mission, I still want to share back here and help the project as much as I can.

Most of my contributions in the past year have been focused on getting... well, everything I could for 2.0, without much reasoning, besides: "get shit done!".

Now that we are a few bug-fix-releases past 2.0, and it I truly believe it looks a lot better than 1.7, with the most obvious regressions addressed, I was wondering if we should talk about 3.0 in a more explicit way.
Of course it does not have to be committal, but I guess it would be nice to get a sense of what matters to peeps and the project, what are the most important pain points, what kind of new features we would like, etc.

I am not sure what is the best medium for that, but right now maybe we can start with just this ticket, and I can update the description here with items people are proposing.
Maybe we can post one idea / feature / bug per comment, along with a very simple "priority" (P0: MUST!, P1: should get it done, P2: nice to have), and then peeps can thumb up?

Do you folks have thoughts overall? (I have many, but I would rather keep them for myself for now so that I do not flood the conversation).

Tagging @junnplus @ktock @yankay @austinvazquez @Zheaoli @manugupt1 @haytok @sondavidb @xyz-li @TinaMor @jsturtevant (sorry if I forgot you...).

[sondavidb]

Hey, happy new year to you as well!

Wondering if I'm missing any context here — is there something in particular pushing us to plan for the next major release? Asking since 2.0 came out pretty recently, and planning for the next set of breaking changes already seems a bit strange, unless there are important things we must address.

[apostasie]

Hey, happy new year to you as well!

Wondering if I'm missing any context here — is there something in particular pushing us to plan for the next major release?

Just a (personal?) desire to see some structured thoughts on overall direction.

Asking since 2.0 came out pretty recently, and planning for the next set of breaking changes already seems a bit strange, unless there are important things we must address.

It doesn't have to be breaking (new features would not be).
This is very informal, and intent only on gathering what matters to users (and contributors), and areas to focus on.

[AkihiroSuda]

Thanks for heading this up and thanks for all your contributions ❤

3.0

containerd v2.1 is targeted for May 7th, 2025:

• Update RELEASES.md for new release schedule and LTS policy containerd#11294

So we may sync the release of nerdctl v2.1 with containerd v2.1.

I still don't see a reason to bump up the major version.

Although my fork has now diverged significantly and is pursuing objectives that are not aligned with nerdctl mission, I still want to share back here and help the project as much as I can.

Maybe we should introduce a build tag like nerdctl_no_experimental to disable experimental features of nerdctl so as to reduce divergence?
We also have an env var NERDCTL_EXPERIMENTAL=false.

[fahedouch]

For roadmap I know that we maintain a word document that is refined each community meeting.

nerdctl remains a containerd client so it is complicated to talk about nerdctl 3.0 before containerd plans one.

[apostasie]

For roadmap I know that we maintain a word document that is refined each community meeting.

Is this something that can be shared with the larger community or is it an internal document?

[apostasie]

Thanks folks!

I should not have said "3.0" (removing it from the ticket title) - the important part IMHO is more in the "roadmap" part rather than which version number would that be.

As far as I am concerned, here are the things I think currently matter:

Quality

While a large amount of effort has been invested and many bug fixed, nerdctl is still failing (randomly).
For the most part, flakyness is no longer a manifestation of broken tests, it is underlying code issues / racyness.

This is particularly true of:

• CNIEnv (CNIEnv concurrency issues #3556)
• the obnoxious “Layer not found” (content digest not found #3513)
• overall the multi-platform code that is largely broken (Multi-platform image code is broken #3516 Suggesting we rewrite (parts of) imgutil #3531).
• logging is also flaky / racy

Additionally:

• locking may cause issues with third party software ([Cilium] Executing nerdctl run in k8 environment is stuck #3783), as some software like Cilium will try to acquire locks in the same locations as we do
• compose shelling out is structurally racy and cannot be fixed - we should rewrite without shelling out
• ImageWalker and ContainerWalker are a source of issues and should be phased out
• windows still is quite trailing in term of quality, with recent regressions and long lasting issues (Failure on image pull: UtilityVM: Incorrect function.: unknown microsoft/hcsshim#2294)

Nerdctl as a library / to build other cli

Delimitation is currently fuzzy between cmd (“parsing arguments”), pkg/cmd (“displaying results), and the rest of pkg that should ideally provide high-level functionality unencumbered by argument parsing or output. A good example of that is pkg/api, that is actually just options for pkg/cmd. Overall, there is no clear nerdctl-API that would not involve display or argument parsing.

Also, “nerdctl” is (logically) deeply ingrained inside the codebase, making it hard to create a new cli that would have separate storage location, etc.

Finally, it would be desirable to be able to leave optional features out at compile time (as suggested above).

Developer experience

CI is too slow:

• we should finish rewriting tests (compose and containers) using the new test tooling to clean-up tests and fully leverage parallelism
• GHA cache is a can of worms
• Dockerfile currently does two things at once (release and test rig), which is a problem
• Dockerfile is also too slow for local testing (source code is copied instead of mounted, forcing one to rebuild everytime you want to re-run the tests)

Test images are problematic:

• single platform, impeding ability to test on ARM
• grossly outdated (windows busybox)
• windows collection is very lacking

Overall, windows testing is currently subpar and very limited.

It should be easily possible to test locally outside of inside the Docker container (#3858).

Finally, we should get rid of dependencies (unbuffer, tar, nsenter, maybe aa-exec), and provide simpler ways to just install required developer tools

Thoughts?

Let me know if you folks have any thoughts about these - or other ideas.

Take care!

[AkihiroSuda]

Also, “nerdctl” is (logically) deeply ingrained inside the codebase, making it hard to create a new cli that would have separate storage location, etc.

Probably "nerdctl" should be a variable that can be overridden