docker-baseimage-alpine
docker-baseimage-alpine copied to clipboard
linuxserver
s6-overlay v3
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
It's not a easy upgrade, we have looked at it, and need to find a way to make it backwards compatible, while keeping mod support etc
I just found out the hard way that s6-overlay is v2.2.0.3 when I went to setup: /etc/s6-overlay/s6-rc.d and (.../user/contents.d) and nothing started up correctly. I should have doubled checked first before sponging the s6-overlay v3 documentation.
Tossing out an idea for moving forward. How about either mucking with the image name or the tag since the base image and s6‑overlay are tightly coupled (e.g.):
- .../docker-baseimage-alpine-s6v3:3.15
- .../docker-baseimage-alpine:3.15-s6v3
This could provide an intermediate upgrade path for those wanting to use the newer s6 v3 system and forgoing backwards compatibility with v2. Somewhere along the way, a hard cut will need to be made. This would at least allow a jumpstart and get the newer s6 v3 integration out in the wild for testing.
FYI, we started looking into s6 v3 back in January. The main issue at the time was the init system changed drastically and broke the method we use to apply docker mods during the init. There is now a public branch and draft PR as of writing, https://github.com/linuxserver/docker-baseimage-alpine/pull/93
We still have more to work on. s6 v3 output is different, and our CI tests rely on something specific to v2. We're considering the options to try and get v3 rolled out while maintaining backwards compatibility while s6 still supports it. You can follow the progress in the PR. The same or similar changes will be applied to our other base images once we've nailed it down with alpine.
No decision has been made yet about rolling out s6 v3 to anything other than the newest of each base image (ex: ubuntu jammy will likely get it - focal may not, bionic almost certainly won't - alpine 3.14 likely will not, etc).
V3 is very powerful and has really cool features, but migration is a pain and there is a steep learning curve
Also, FYI for those following, s6 v3 does not break backwards compatibility with v2 cont-init or services. They are referred to as "legacy" but not listed as deprecated at this time. This should mean that when we are able to get everything we need working, users would be able to use either v2 style cont-init and services, or v3 style rc, or possibly even both at the same time. There does not need to be a hard cut off until s6 deprecates and removes support for v2 style cont-init and services.
Well, to me some things brokes, so I will keep with v2. It' looks like Objective-C to Swift, for iOS dev, "similar" but a new language. Anyway, thank you to all devs that make S6 better, even if we need to relearn to use it. Just my opinion.
Hey, primary s6-overlay v3 author here. Thanks for working on this; if there are things I can do to help the migration to v3, or questions you have that I can answer, feel free to ask.
We were having a lot of open issues with v2 that could not be solved without a complete rework, and that had been festering for years - so when I set to work on v3 I didn't consider the images that were relying on v2 mechanisms, especially if you have to patch. Sorry about that; I wanted to ship something that worked ASAP, and then tweak if necessary. I think it was a good decision: v3 is much, much easier for us to maintain and fix than v2 was.
The difference in container output between v2 and v3 was unavoidable; we will try not to change what we print in the future, but cannot guarantee it. I really recommend not relying on parsing output if you want to probe functionality; if there are specific things you need to check for, I'm willing to help you find alternative solutions to do what you want.
We have no plans at the moment to deprecate cont-init, cont-finish and services.d. We're aware that a lot of people rely on them and do not intend to break their habits. The s6-rc service model is more powerful and more efficient, but we're not going to force people to use it if they don't want to. (However, if questions come up that are solved by the s6-rc model, e.g. about service dependencies and startup notifications, we will definitely encourage migrating.)
Cheers,
Hey, primary s6-overlay v3 author here.
Hey @skarnet ! It's awesome to see you're keeping an eye on our projects. We are still working on getting where we feel we need to be with v3 and do actually have some questions. Would you be interested in chatting with us about it on our discord https://discord.gg/YWrKVTn ?
If yes, DM me (iXNyNe in the server) once you've joined.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.