search

riotkit-org / docker-taiga

Production-ready docker container for Taiga https://taiga.io
https://quay.io/repository/riotkit/taiga?tab=tags
GNU General Public License v3.0
55 stars 8 forks source link

Do we still need this image, when there is Taiga 6? #48

Open blackandred opened 3 years ago

blackandred commented 3 years ago

Hi,

I'm opening the discussion - what's good in this image that should keep it still maintained even if there is a official image now? I'm not familiar so far with the official container, so I need some feedback.

Please assume that if our image would stay then it would be up-to-date with Taiga 6 anyway.

blackandred commented 3 years ago

If there will be no greater advantages I would be for using the official image to maintain less things.

zicklag commented 3 years ago

I definitely think it would be good to move over to the official container, it'd be better not to maintain more than we need to, but LDAP is the blocker for me right now: https://github.com/taigaio/taiga-docker/issues/48.

blackandred commented 3 years ago

I would suggest to refactor our container with this idea:

So we would have everything prepared by Taiga official maintainers + our simplified setup. I personally do not see benefit of separating between frontend container and backend container. It scales in the same way, even easier is to scale single container - the frontend is static, so who cares which container will serve it.

zicklag commented 3 years ago

:+1: I like the sound of that. :slightly_smiling_face:

blackandred commented 3 years ago

I have read that thread, regarding the LDAP possibly we need to add it by our own because the plugin is unofficial and I don't think that Taiga maintainers would include an unofficial plugin.

marshalleq commented 3 years ago

The reason I use this container, is because it doesn't need docker compose. I run on unraid (as I am aware others do too), which does not support docker compose officially and we haven't actually managed to even get the official container to work.

What I wish this container had was a working message queuing system, but at least it works which is a win.

I've not been using it for a while, but have firmed up the resources for a new project which I am now (hence I am here today reading) re-looking at which docker to use. I am again faced with the same issues apparently, though I haven't figured out what might have changed between v5 and v6 in terms of the messaging queuing (i.e. someone drags a card and others can see this too without having to refresh the browser).

Any some point I hope I can include the fix for this inside of another project, but that won't be for a while I suspect.