storage mount still missing in v11

[stefanstidlffg]

As far as I see, there is still no persistant storage for attachments in v11 release of docker-compose files.

See:

For anyone who has moved to file storage, there also needs to be a mount for that: path-to-zammad-storage:/opt/zammad/storage

Originally posted by @yogo1212 in https://github.com/zammad/zammad-docker-compose/issues/348#issuecomment-1609716709

[MrGeneration]

I don't think that this should exist in the default compose file as it's an optional configuration that you can do, but don't have to. Thus you should add this on your own.

At least in my opinion.

[yogo1212]

@MrGeneration While I get that it's not necessarily the default, it is recommended to use the file storage backend by the official documentation.

We strongly encourage you to use filesystem storage on busy instances. This will greatly improve system performance (de-crease database load and size).

Before the switch in v6 (keeping code out of the volumes and strictly tied to the container - a good change, imho), no change to the deployment was necessary because /opt/zammad was mounted in. With the change, I'm convinced that either the documentation or the compose file (or both) should at least mention that the storage directory must be mounted. Finding this out by accident means 'data loss' (data is written to the container overlay and is deleted when the container is removed).

Same goes for Store::File.move - that isn't mentioned anywhere in the docs (they only mention that there is a way to do that).

I wonder what the policy is there. Making stuff like this hard isn't going to convince people to go for the service solution. There might be a completely different reason - but that is the dominant line of thinking when information is unavailable or unknown.

We switched from 'service' to 'self-hosted' to increase our control over data and backups. Such hurdles aren't going to revert the decision, they encourage thinking about other solutions.

[MrGeneration]

it is recommended to use the file storage backend by the official documentation.

I know, it's actually my sentence. Any way, earlier in the docker days I would have never recommended it for various reasons.

My view on this may have changed over time.

Same goes for Store::File.move - that isn't mentioned anywhere in the docs (they only mention that there is a way to do that).

That's clearly a missing piece of information, you're right with that! This should live in the console documentation section of https://github.com/zammad/zammad-documentation

With the change, I'm convinced that either the documentation or the compose file (or both) should at least mention that the storage directory must be mounted. Finding this out by accident means 'data loss' (data is written to the container overlay and is deleted when the container is removed).

That's a very good point. If you want you can create a pull request for this?

I mean as a commented out version in... umm I guess override to provide a hint. Might also need an issue in the documentation so it hints for it. However, I'm not sure how the current documentation plans are there. I'm completely decoupled from that process for a while now.

I wonder what the policy is there. Making stuff like this hard isn't going to convince people to go for the service solution. There might be a completely different reason - but that is the dominant line of thinking when information is unavailable or unknown.

We switched from 'service' to 'self-hosted' to increase our control over data and backups. Such hurdles aren't going to revert the decision, they encourage thinking about other solutions.

You're welcome and free to use either SaaS or on Premise. It doesn't matter. It's your data and your decision. Even without a support contract my above statement stays the same.

I have hard feelings about people not updating their installations but not people not contributing or not "inserting coins". I would appreciate it though, if you wouldn't put out those kind of statements, they may hurt feelings you know.

[mgruner]

@stefanstidlffg @yogo1212 can you please check #380 to see if this addresses the concern properly?

[yogo1212]

That's a very good point. If you want you can create a pull request for this?

I'm too slow. Thanks, @mgruner !

You're welcome and free to use either SaaS or on Premise. It doesn't matter. It's your data and your decision. Even without a support contract my above statement stays the same.

About that: Are there any options for one-time donations?

I have hard feelings about people not updating their installations but not people not contributing or not "inserting coins". I would appreciate it though, if you wouldn't put out those kind of statements, they may hurt feelings you know.

Completely fair point - sorry! While I was primarily trying to outline how a thing like this can negatively impact decision making rather than exerting pressure, I totally understand that it can be hurtful for the ones involved.

[MrGeneration]

About that: Are there any options for one-time donations?

Right now the only option to actually donate is to do this via the Zammad foundation: https://zammad-foundation.org/donate/

If you require an invoice, I'm sure our sales can figure something out as well.