[root@ebb-ns8-dev scratchpad]# cat odoo-community-reply-stephdl.md
Thanks, good pointer. Honest answer: not so far. The modules were built against the developer manual and by reading existing modules (e.g. ns8-sogo and friends), I only saw NethServer/agents through your post.
I have read the ns8-module skill now. Most of its “always applies” rules match what we already do: authorizations declared as labels in build-images.sh, logs to stderr, state-include.conf for the volumes.
One rule we do not follow everywhere yet: secrets. Several modules keep passwords in the module environment via agent.set_env(). Your skill says that lands in Redis in plain text and asks for state/passwords.env (0600) plus EnvironmentFile/–env-file instead. That is a fair point.
To put it in proportion: for the most part this concerns generated start values, i.e. the internal database passwords (only reachable inside the pod on loopback) and the initial admin password that is meant to be changed at first login. A bit more critical are the LDAP bind passwords for directory login. But those belong to read-only service accounts anyway, and the same credentials can already be made visible elsewhere, in the Samba / account provider UI, through the same “eye” mechanism. A few modules also hold a secret the admin typed in (an SMTP password, an API key), so I will move all of them over, not only the generated ones. Odoo goes first, the others follow module by module as normal point releases.
I have installed the plugin for the clean-up and for the next modules. If you spot other things in tebbiworld/ns8-* that go against your conventions, I am happy to hear them.
I am running anything on a seperate dev VM with integrated claude code (max / fable 5.1) via SSH. I
That matches how we work already. Everything runs on a separate dev node, a VM that is not production, and Claude Code (Max plan, Fable model) sits directly on it with a root shell. It installs the module there, reads the journal, fixes what breaks and tests again, largely on its own. My part is mostly to provide tokens and ideas: I write the user stories and try the result from the user side.
Also the nethserver-admin fits in nicely. It is installed now together with the other skills, and the ns8-module one is already being used to go through all our modules against your conventions. I also picked up your ns8-ci-actions workflow for install and update tests on real nodes, one module at a time so the runners are not flooded.
Hmm. Long the discussion was, my young padawan. Right, Jedi master Stéphane is.
Old I am. Eighteen modules built I have. Yet the conventions, read them I did not. The quick path I took, the easy one. Passwords into the environment, into Redis, in plain text they went. Tempting the fast way is. To the dark side of development, it leads.
Free the tokens on my Friday seemed. Free, the lesson was not.
Humble even an old Jedi must be. Still learning, I am. Taught me Master Stéphane has, and listen I did.
Odoo first, clean it will be: state/passwords.env, mode 0600, EnvironmentFile. Then the other modules, one by one, as point releases they follow. Patience this path requires.
My wisdom, share it I will, young Padawans:
Buy tokens, you may. Use the skills, you must.
Without the skills, fast the AI writes. Fast into the swamp. With the skills, guided by the conventions it is.
and friends), I only saw NethServer/agents through your post.
