Warning on Ubuntu: Docker version is not supported: Got 24.0 – (edited, hint: currently only tested with 26.0)

[acsr]

PreRerequisites

I tried starting a new Plone6 Project on a fresh Ubuntu LTS 24.04 Server Instance with dependencies already installed following the instructions at https://6.docs.plone.org/install/create-project-cookieplone.html

Result of pipx run cookieplone --version:

Cookieplone 0.7.1 from /home/astro/.cache/pipx/80aa0c0b5fc1b26/lib/python3.12/site-packages/cookieplone (Cookiecutter 
2.6.0, Python 3.12.3 (main, Sep 11 2024, 14:17:37) [GCC 13.2.0])

Made with ❤️ by the Plone Community

Issue

I get a Docker Version warning:

Sanity check results:
- Python: ✓
- Node: ✓
- git: ✓
- Docker (optional): Docker version is not supported: Got 24.0

Question

Why is this warning generated, and where does the not supported setting comes from?

Why? Looking at the code no idea why…

In the cookieplone code there is only one place found by me where the Docker version is mentioned:

cookieplone/cookieplone/settings.py

Line 25 in 1f46ed8

MIN_DOCKER_VERSION = "20.10"

MIN_DOCKER_VERSION = "20.10"

My Versions

I use this script to list the requirement installed versions:

echo "List currently locally installed versions of Plone CI fullstack tools"
echo "-----------------------"
echo "python3.12 version: "`python3.12 --version`
echo "pipx version: " `pipx --version`
echo "nvm version: " `nvm -v`
echo "npm version: " `npm -v`
echo "node version: " `node -v`
echo "make version: " `make -v`
echo "gmake version: " `gmake -v`
echo "git version: " `git -v`
echo "Docker version: " `docker --version`
echo "-----------------------"
echo `date` Done!

result:

List currently locally installed versions of Plone CI fullstack tools
-----------------------
python3.12 version: Python 3.12.3
pipx version:  1.4.3
nvm version:  0.39.5
npm version:  10.8.2
node version:  v20.18.0
make version:  GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
gmake version:  GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
git version:  git version 2.43.0
Docker version:  Docker version 24.0.5, build ced0996
-----------------------
Mi 13. Nov 14:06:04 UTC 2024 Done!

one more thing related to version pinning (maybe need another ticket as well later):

I also got: Node version is not supported: Got v22.11.0 after just using nvm install --lts as described at https://6.docs.plone.org/install/create-project-cookieplone.html#node-js

even when version 22 is allowed and listed in cookieplone/settings.py

I could fix it there with: nvm install --lts=iron ending up with node version: v20.18.0

[acsr]

Need to update to latest Cookieplone 8.0.0 and retry

[acsr]

same with Cookieplone 0.8.0

[davisagli]

@acsr First thing: Docker is optional, like it says. If you don't plan to use the commands which build and run Plone inside containers, you can ignore this warning.

The minimum version is currently set to 26 in the project template: https://github.com/plone/cookieplone-templates/blob/main/project/hooks/pre_prompt.py#L50

The choice of 26 is somewhat arbitrary because that's the version I had installed when I added the check. There's a good chance that older versions work fine as well, but I didn't have a way to test that. If you try it and find that things work fine on Docker 24, I would be happy to update this check.

For the Node 22 version check, a fix was merged yesterday (#49). @ericof, we need a new release with this, please.

[acsr]

OK, thanks for the clarification. This is indeed a warning only, but when your whole stack fails day after day, you can try to workaround, but cannot be sure if there is something in the guts a greasemonkey failed to fix. The namespace issues etc.

When I was was trying to get this to work earlier in february, there were these yarn issues driving you crazy. Since I am targeting the Ansible stuff and building the images, docker seemed to be important for me. In feb it took several strong attempts to work around these obstacles (i18n testing not working, blocking the image generation etc.). Each obvious at the end but not discoverable in the docs in advance.

Why? The docs were written from a "knowing" perspective and obvious stuff was just mentioned implicit.
Instead we need explicit copytext writing for every sh... leaving nothing in the fog.

Please take that into mind.

Suggestions

When you only have tested just with Docker 26, I suggest to write exactly this and explicitly

"Currently only tested with docker 26: Got 24.0"

instead of just "Docker version is not supported" which reads aka not working at all.

In the settings.py there is only a Docker min 20.x constraint obvious. This together with "Docker version is not supported: Got 24.0" reads as "You may need an older version"

On the Plone 6 Installation docs (Offtopic here, but valueful)

Developers are not always good copywriters. To fix the docs I need to have a fork of the docs in place. I used to do that with older versions and promised to dive in again, but even docs to contribute to the docs sucks.

I remember the work of Mikko to throw everyone not contributing properly into the bay of Naples to feed the sharks, but also simplify the process… Maybe we need to start there. @stevepiercy ist doing great efforts, but it was not easy for me to dive in until now.

Outlook for Cookieplone

I really like the possibilities of Cookiecutter and it is my choice to avoid overwhelming documentation.

How? Let Cookiecutter create more background output using a verbose option. It is nice to reduce interactivity using replay and prerequisites, but the other way round would be also nice. Lets see how I can contribute.

@davisagli you commented in #17
This is the way to go to avoid these drawbacks. This is killing the Plone Experience for Plone6! I get this Feedback from different sides by long time Plone Advocated fighting with just to get the stuff going.

[acsr]

I had the docker snap installed by default using the 24 version.

Name        Version               Rev    Tracking       Publisher              Notes
docker      24.0.5                2932   latest/stable  canonical✓             -

• removed the snap using sudo snap remove docker and reinstalled following the procedure here
  https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

• used the Specific version method -> setting the Version string to latest 26:

  VERSION_STRING=5:26.1.4-1~ubuntu.24.04~noble
  

[acsr]

I can confirm cookiecutter 0.8.1 is starting up with node v22 and docker 26 without warnings. I give the docker 24 a try when I get the rest basically to work. THX @davisagli and @ericof for the fast reaction and new release.

[stevepiercy]

Developers are not always good copywriters. To fix the docs I need to have a fork of the docs in place. I used to do that with older versions and promised to dive in again, but even docs to contribute to the docs sucks.

What specifically—as you so elegantly state—sucks about them?

What would improve them?

I put a lot of effort into making it easy to locally build and contribute to docs. If it is not easy, then I've failed.

For almost the last three years, I've been diligently serving as copy editor. I expect developers and non-native English writers to make mistakes, and mistakes are perfectly OK. If your primary language is Sanskrit, then write docs in Sanskrit, and I will use various translation tools to figure it out. I can work with them.

My only expectation is that the technical steps be correct. I lack the technical knowledge of how to do things in Plone, as I am a relative Plone n00b.

[acsr]

@stevepiercy maybe my words seem to harsh. My point is, that I am still struggling with serious painpoints in the docs. e.g. no Troubleshooting FAQ with common known mistakes you can get stuck with. I know GIYF but I am currently listing them for me and hopefully can contribute back.

1. Contributing to Documentation is currently buried under Contributing to Plone in the Table of Contents of the Plone6 docs.

2. Suggest edit is buried under the Github Octocat Icon at the top of the page (Icons without text need to be learned! In particular when the topic is a subtopic where icons simpoly do NOT work even if the purpose seems obvious for the sender, for the receiver definitely NOT, because it is lacking the context in the brain of the author. Therefore you have to be explicit as sender, when you cannot make sure the whole is communicated mandatory.

3. I would suggest to have a prominent permanent side tab with the unmistakable message:
   Improvement Welcome – Start here…
   and a repeated instance in the footer.

The whole text at about contributor roles and requirements is disencouraging as long as just pointing to misleading stuff as feedback is welcome. This is why these simple requests: Was this helpful as Star Ratings were created offering a freetext field to let your emotions run. Never ever let an input in this field touch your personal mood ;-)

One more point: The well understandable requirements for "First Time Contributors" are a bit of disencouraging as well for improving just docs. I started my first contributions to Plone with docs for the Plone 3 theming story by wrapping up stuff from listening in a workshop Denis Msihunov during the Naples Conference in 2007. Writing docs can jumpstart your understanding in an impressing way.

To get an idea what I mean visit this page from my archive thats is still present in the web:
https://opensourcehacker.com/2012/01/08/readthedocs-org-github-edit-backlink-and-short-history-of-plone-documentation/

This short wrapup of the procedure was present on every Docs page and lead me to my first docs contributions:

I hope I come back with serious improvements, but first I need to get this to run, run, run…

Please take this not personal!

Its not the correctness of the steps, but the elegance how to jump in as an easy going.

What is the best place to move this a bit distracting discussion from here?
On the other hand a proper cookieplone workflow can cut away efforts to describe troubleshooting by avoiding the mistakes upfront.

If we write and test docs having the knowledge of the development and docreading experience in mind and think further how to put this at the fingertips during cookieplone setup using a chatbot like experience could improve the setup successrate enormously.

Important Note mentioning the inspiring work: The example shown above is the work of Mikko Ohtamaa, I mentioned earlier in this ticket here: #50 (comment)

[stevepiercy]

@acsr thanks for the feedback. I opened a new issue in plone/documentation#1778. I'll respond there to avoid hijacking this issue any further. You have a lot of good suggestions, and I think we can implement most, if not all, of them.

[acsr]

@stevepiercy thanks for the resonance! All said! Lets go at #1778 for it!