docs: secrets: a bit of wording

[jtagcat]

https://overnode.org/docs/configs-and-secrets-storage

A cluster of distributed hosts does not have such a local directory equally available for all of the hosts unless you opt into some sort of network file system.

-> A cluster of distributed hosts does not have a local volume available for all the hosts, unless you opt in to a form of a network file system.

[jtagcat]

Overnode takes a simpler approach. It uploads the contents

The whole 2 paragraphs are very wordy and caused me to stop a few times in confusion.

[jtagcat]

The whole page should be refactored

[jtagcat]

played with -> used

[jtagcat]

Clarification: is this suitable for only secrets/configs, may the configs be changed while running (and synced to other nodes?), or also caches, light persistent data?

It also sounds dumb that on the down command, the working dir is reverted aka deleted. Is it really deleted?

[jtagcat]

overall, the dirs should be synced while container is offline, to avoid conflicts and better HA.

[avkonst]

I will see how it can be improved. I will answer your questions a bit later

[jtagcat]

I can attempt to mostly refactor the page, as I understand the topic. So far (rn at pre-confed infra) this has been the hardest page to understand by wording, not by technicalities.

[avkonst]

is this suitable for only secrets/configs

It is suitable only for secrets / configs. Should be used as readonly mounted folder. The only way to modify these configs it by changing it in a project directory and running 'up' to reupload.

may the configs be changed while running (and synced to other nodes?),

No it is not allowed

or also caches, light persistent data?

Containers should create/mount a separate volume for it. If a container has got persisted state, which requires distribution, it should use proper database for this, like etcd.

It also sounds dumb that on the down command, the working dir is reverted aka deleted. Is it really deleted?

Yes, it is because all the persisted state produced in runtime by a container should use a dedicated volume for it (or a database, if it requires synced distributed state).
It is actually not a working directory. It is more like a '/etc' and '/var' on Linux - etc is configs, var is for runtime data. Deleting configs on down is not an issue, because it is only a readonly copy from the current state in the project folder.

[avkonst]

overall, the dirs should be synced while container is offline, to avoid conflicts and better HA.

Because it is readonly config, which are read usually only on start up, it is not an issue to replace while online. Some containers actually rely on hot swap of a file content. For example, nginx can pick up new content. Grafana picks up new dashboards by watching a directory. There are many other examples.

I guess it can be still an issue for some containers, but I can not think of some. Docker Compose / Swarm certainly does not solve this issue (ie. have not seen or ignored). If we encounter such a case, it can be possible to implement opt-in feature, which will enable upload to a unique directory each time when 'up' is invoked. In this case, containers relying on OVERNODE_ETC volume will be recreated with every 'up' command.

Makes sense?

[avkonst]

Keep the ticket to extend docs, so it answers the questions about runtime generated persisted state