How to connect Taiga to Events server?

[marshalleq]

Thanks so much for building this, I've spent about 4 days going round in circles before finding this starting at ben Hutchins repo but not liking that it was out of date, ended up building a whole vm which worked perfectly but refused to use our reverse proxy properly, then found this when looking at the issues section at benhutchins repo. :). It's amazing!

Can you give me any hints on how to set up the events server?

I don't mind writing up a doc in return or something, I'm just a bit confused about which bits are needed for this docker vs what would normally be needed for a typical setup e.g. VM.

I assume I need to:

1 Install a redis container
2 Install rabbitmq container
3 Install the official events server from taiga
4Configure TAIGA_ENABLE_EVENTS, TAIGA_EVENTS_HOST, TAIGA_REDIS_URL, TAIGA_BROKER_URL
5 Configure whatever needs to be configured in the above containers

That's my thought anyway. Any help would be appreciated!

Marshalleq

[blackandred]

Hi, the events are handled by a separate server. The Taiga docs is saying that this step is optional, so currently we skipped implementing this in the container.

I suggest to create a second container in second repository to provide the events container as a separate docker container. I can start this and we can cooperate in next weeks if you want.

If you need it now, then I suggest to set up the events server without docker and set the environment variables to point at it.

[blackandred]

PS Changing title, so we will know what's it is about 😉

[marshalleq]

Wow that sounds fantastic thank you!

It's not urgent, but it would help quite a lot with remote working. I've been displaced by COVID-19 and trying to get a startup off the ground from another country to which it started, so you can imagine, remote tools are where it's at. There's only two of us at the moment - early days. But am enjoying the experience of working with tech again.

Also, as benefit to others, it's probably worthwhile to share how this fits together from an architecture perspective. I find most of the guides don't explain it thoroughly enough. I've started a diagram in draw.io (from VM perspective which I attach and can modify and share for final result.)

Am excited to have your support!

[marshalleq]

Hey, any progress on creating a container? Probably I should finish my gitlab setup, but haven't gotten there yet!

[blackandred]

Hi, I'm thinking about it. Possibly in this week I can try to do something working.

…

On Thu, May 21, 2020 at 8:43 AM marshalleq ***@***.***> wrote: Hey, any progress on creating a container? Probably I should finish my gitlab setup, but haven't gotten there yet! — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOAJBQZTC7ZEGWGQMKMYZDRSTESTANCNFSM4MYKFJYQ> .

[blackandred]

I started a image+CI project there https://github.com/riotkit-org/docker-taiga-events
It looks that it will be working very soon. I will tell you when it will be testable, then please send me feedback if it is working in your setup.

[blackandred]

I see you need to set up TAIGA_EVENTS_HOST=somehost:8888 to point to Taiga Events. I didn't do any integration testing yet - I would leave it to you for a feedback, then we can prepare a tutorial.

[marshalleq]

Wow thanks, so you're saying it's ready to test?

Edit - I see the docker image is live. Giving it a go. :)

Thanks.

[blackandred]

Please try, and as a contribution at least please if you could do some instruction :) The server is getting up and responding to requests, but I didn't do any integration testing between Taiga and Taiga Events server yet. *Please note:* *The Taiga Events server is a less frequently maintained project, it is even not versioned properly (notice the commit id in docker tag), so we can only hope that it is stable :)*

…

On Sat, May 23, 2020 at 2:46 AM marshalleq ***@***.***> wrote: Wow thanks, so you're saying it's ready to test? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOAJBWBDMSQZUE7LUXYEXTRS4MGBANCNFSM4MYKFJYQ> .

[marshalleq]

I made a good start on it yesterday. I quickly realised it has it's own dependencies, namely RabbitMQ, Celery and Redis. To add to the complexity, the celery container is now deprecated and they say to manually install it with python.

The taiga architecture is a little bit confusing in this regard, but we'll get it going I'm sure. In the long run if we can figure out how to get this running separately I assume we'll be able to combine it all into a single container for simplicity?

I am a little concerned about how I'll get celery working at this point, but will try pushing forward with the deprecated container for now.

Thanks.

[blackandred]

Hi, in my understanding of https://taigaio.github.io/taiga-doc/dist/setup-production.html#taiga-events , the Taiga Events + RabbitMQ is for hot-reload functionality. The Celery + Redis is for asynchronous processing of background tasks. That's two different things.

…

On Sun, May 24, 2020 at 12:21 AM marshalleq ***@***.***> wrote: I made a good start on it yesterday. I quickly realised it has it's own dependencies, namely RabbitMQ, Celery and Redis. To add to the complexity, the celery container is now deprecated and they say to manually install it with python. The taiga architecture is a little bit confusing in this regard, but we'll get it going I'm sure. In the long run if we can figure out how to get this running separately I assume we'll be able to combine it all into a single container for simplicity? I am a little concerned about how I'll get celery working at this point, but will try pushing forward with the deprecated container for now. Thanks. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOAJBVI7QMM6KPNF2AHLMTRTBD6VANCNFSM4MYKFJYQ> .

[Sawrz]

Hi,
Thank you for this awesome image. Recently I tried a different one, but this one is superior in terms of simple setup. Great work!

So I played a bit with the events too, and taiga didn't crash when I enable events. However, in my understanding, "hot reload" means that the user doesn't need to reload the webpage to see changes, right? Although I don't get any errors, that part doesn't seem to work.

I redirected the events container to 443, and the webpage told me, "upgrade required." Maybe a bug?

Here is my docker-compose file:

version: "3.7"

services:
    database:
      image: postgres:${POSTGRES_VERSION}
      container_name: taiga_db
      environment:
        POSTGRES_DB: ${DB_NAME} 
        POSTGRES_USER: ${DB_USER} 
        POSTGRES_PASSWORD: ${DB_USER_PASSWORD} 
      volumes:
        - type: bind
          target: /var/lib/postgresql/data
          source: ${ROOT_DIR}/db
      networks:
        - backend

    taiga:
      image: quay.io/riotkit/taiga:${TAIGA_VERSION}
      container_name: taiga_server
      depends_on:
        - database 
      volumes:
        # all data placed in volumes are kept between container updates/deletion/recreation
        - type: bind
          target: /usr/src/taiga-back/media
          source: ${ROOT_DIR}/media
      environment:
        - "DEBUG=False"
        - "TAIGA_HOSTNAME=${URL}"
        - "TAIGA_SCHEME=https"
        - "TAIGA_SECRET_KEY=${SECRET_KEY}"
        - "TAIGA_DEFAULT_LOCALE=${DEFAULT_LOCALE}"
        - "TAIGA_ENABLE_WEBHOOKS=${ENABLE_WEBHOOKS}"
        - "TAIGA_PLUGINS=${PLUGINS}"
        - "TAIGA_ENABLE_EVENTS=${ENABLE_EVENTS}"
        - "TAIGA_EVENTS_HOST=taiga_events"
        - "TAIGA_BROKER_URL=amqp://${RABBIT_USER}:${RABBIT_PASSWORD}@taiga_broker:5672"
        - "TAIGA_REDIS_URL=redis://redis:6379/0"
        - "TAIGA_DB_HOST=taiga_db"
        - "TAIGA_DB_NAME=${DB_NAME}"
        - "TAIGA_DB_USER=${DB_USER}"
        - "TAIGA_DB_PASSWORD=${DB_USER_PASSWORD}"
      labels:
        # Reverse proxy and certificate
        - "traefik.enable=true"
        - "traefik.docker.network=reverse-proxy"
        - "traefik.http.routers.taiga.tls.certresolver=myresolver"
        # Website Configuration
        - "traefik.http.routers.taiga.entrypoints=websecure"
        - "traefik.http.routers.taiga.rule=Host(`${URL}`)"
        - "traefik.http.services.taiga.loadbalancer.server.port=80"
      networks:
        - backend
        - reverse-proxy

    broker:
      image: rabbitmq:3.8.4-alpine
      container_name: taiga_broker
      environment:
        RABBITMQ_DEFAULT_USER: ${RABBIT_USER} 
        RABBITMQ_DEFAULT_PASS: ${RABBIT_PASSWORD} 
      volumes:
        - type: volume
          target: /var/lib/rabbitmq
          source: broker
      networks:
        - backend

    taiga-events:
      image: quay.io/riotkit/taiga-events:2de073c1a3883023050597a47582c6a7405914de-SNAPSHOT 
      container_name: taiga_events
      depends_on:
        - broker 
      environment:
        BACKEND_SECRET: ${SECRET_KEY}
      networks:
        - backend

volumes:
  broker:
    name: taiga-broker_data
    external: true

networks:
  backend:
    name: taiga
    external: true
  reverse-proxy:
    external: true

[marshalleq]

@Sawrz that's also my observation. I'm in managed 2 week isolation so it's hard to work on this at present, however I did notice some hard coded things inside the taiga container the other day that I suspect may be causing issues. e.g. redis, celery, rabbit. Maybe check there. Mines not working yet either and I'd love to get it working as it's really hard working in remote teams without it.

[blackandred]

@marshalleq You can still enter container via docker exec and modify the configs by yourself, then do a restart of Taiga via supervisorctl (https://github.com/riotkit-org/docker-taiga#troubleshooting).
With trail and error method you can find out what's required to be configurable via env if there is something missing and let us know.

[blackandred]

@Sawrz Did you maybe check how this works on Taiga Cloud version? I mean if you click something from other browser is it reloading? I guess they should be using events and all of the stuff they made.

By the way I would be cautious with the events - it looks like an abadonned part of Taiga, it may work or not work, they even do not version the events server correctly - it's all the time a DEV version 😉

[blackandred]

@marshalleq

I see you are using Traefik, I don't know if you are using it properly actually.

Please consider the fact that we mix-up the routes on single port, and on single domain for Taiga Backend & Taiga Events. That could be cause of your problem now - events are now visible for browser.

See: https://github.com/riotkit-org/docker-taiga/blob/master/container-files/opt/taiga-conf/nginx/nginx.conf.j2#L76

EDIT:

Ok, my bad. The NGINX is actually in Taiga's container. So the used gateway does not matter. Please check if the /events endpoint is responding.

[blackandred]

Do you have any progress on it? :)

[marshalleq]

I don't, we are finally home and have had a lot to sort out. But I did give it a decent go before, my problem is still that I don't know properly how it's meant to be set up from an architectural perspective. I've done what I think should work, checked logs and such, but it still doesn't work. I will give it another go today because I really want this, it's so painful working remotely and having to refresh the browser in case somebody might have changed something.

[marshalleq]

My mental notes and thoughts below, while trying to get this going, hopefully someone can help answer the questions!

OK, so from what you say above, I don't need celery and redis, so I'll skip those and only focus on taiga-events and rabbitmq.

TAIGA EVENTS CONTAINER CONFIGURATION
I add taiga events and configure the following:

BACKEND_SECRET (same as taiga)
Container Port 8888
? Container port 5566
? AMQP_URL amqp://taiga.taiga@MY_IP:5672/taiga

RABBITMQ CONTAINER CONFIGURATION

RABBITMQ_DEFAULT_USER: taiga
RABBITMQ_DEFAULT_PASS: taiga
RABBITMQ_DEFAULT_VHOST: taiga
RABBITMQ_ERLANG_COOKIE: Set to shared secret for now because ?
Management Port: 8383:15672
Default listen port: 6572

TAIGA CONTAINER CONFIGURATION
I add

TAIGA_ENABLE_EVENTS=true
TAIGA_EVENTS_HOST my taiga-events ip
TAIGA_BROKER_URL: amqp://taiga:taiga@my_rabbitmq_ip:5672/taiga

QUESTIONS TO ANSWER
Do i need both taiga events and taiga containers to point to rabbitmq? I don't know, because unclear documentation at Taiga. It wont' matter to have it anyway.

I don't know what to put for an erlang cookie (is this the shared secret?) unclear documentation from taiga, rabbitmq says it is a secret, but I don't have high confidence it's the same shared secret. Taiga documentation - hard when there's not architecture explanation. Perhaps it's not required in this config?

As far as I know websocket is required for http via nginx and somehow that points at one of the docker images on port 8888 and seemingly is required for events as per the documentation. I guess I need to look at the dockers internal nginx config to see if this is right. Anyone else know?

From the documentation here, it states taiga events depends upon Rabbitmq as it's message broker which requires a rabbitmq url and a private key. The secret key is shared between taiga and taiga events and that it's default port is 8888. So I've done that as per above docker configs. But here is the mystery port 8888 again.

ERRORS
With this all configured like this, and no redis configured, or referenced in any of my docker configs I see in the logs of the taiga container the following:

2020-06-07 12:18:26,173 DEBG 'backend' stderr output:
ERROR:2020-06-07 00:18:24,170: Internal Server Error: /api/v1/tasks/44

Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 439, in connect
sock = self._connect()
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 494, in _connect
raise err
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 482, in _connect
sock.connect(socket_address)
OSError: [Errno 99] Cannot assign requested address

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/redis/client.py", line 2165, in _execute
return command(*args)
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 563, in send_command
self.send_packed_command(self.pack_command(*args))
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 538, in send_packed_command
self.connect()
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 442, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 99 connecting to localhost:6379. Cannot assign requested address.


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 439, in connect
sock = self._connect()
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 494, in _connect
raise err
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 482, in _connect
sock.connect(socket_address)
OSError: [Errno 99] Cannot assign requested address

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner
response = get_response(request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
response = self._get_response(request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 187, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 185, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/src/taiga-back/taiga/base/api/viewsets.py", line 106, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/django/views/decorators/csrf.py", line 58, in wrapped_view
return view_func(*args, **kwargs)
File "/usr/src/taiga-back/taiga/base/api/views.py", line 460, in dispatch
response = self.handle_exception(exc)
File "/usr/src/taiga-back/taiga/base/api/views.py", line 458, in dispatch
response = handler(request, *args, **kwargs)
File "/usr/src/taiga-back/taiga/base/api/mixins.py", line 204, in partial_update
return self.update(request, *args, **kwargs)
File "/usr/src/taiga-back/taiga/projects/tasks/api.py", line 218, in update
return super().update(request, *args, **kwargs)
File "/usr/src/taiga-back/taiga/projects/notifications/mixins.py", line 121, in update
return super().update(request, *args, **kwargs)
File "/usr/local/lib/python3.6/contextlib.py", line 52, in inner
return func(*args, **kwds)
File "/usr/local/lib/python3.6/site-packages/django/db/transaction.py", line 267, in __exit__
connection.set_autocommit(True)
File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 416, in set_autocommit
self.run_and_clear_commit_hooks()
File "/usr/local/lib/python3.6/site-packages/django/db/backends/base/base.py", line 651, in run_and_clear_commit_hooks
func()
File "/usr/src/taiga-back/taiga/timeline/signals.py", line 47, in <lambda>
refresh_totals=refresh_totals))
File "/usr/local/lib/python3.6/site-packages/celery/app/task.py", line 427, in delay
return self.apply_async(args, kwargs)
File "/usr/local/lib/python3.6/site-packages/celery/app/task.py", line 570, in apply_async
**options
File "/usr/local/lib/python3.6/site-packages/celery/app/base.py", line 755, in send_task
self.backend.on_task_call(P, task_id)
File "/usr/local/lib/python3.6/site-packages/celery/backends/redis.py", line 294, in on_task_call
self.result_consumer.consume_from(task_id)
File "/usr/local/lib/python3.6/site-packages/celery/backends/redis.py", line 135, in consume_from
return self.start(task_id)
File "/usr/local/lib/python3.6/site-packages/celery/backends/redis.py", line 114, in start
self._consume_from(initial_task_id)
File "/usr/local/lib/python3.6/site-packages/celery/backends/redis.py", line 142, in _consume_from
self._pubsub.subscribe(key)
File "/usr/local/lib/python3.6/site-packages/redis/client.py", line 2229, in subscribe
ret_val = self.execute_command('SUBSCRIBE', *iterkeys(new_channels))
File "/usr/local/lib/python3.6/site-packages/redis/client.py", line 2161, in execute_command
self._execute(connection, connection.send_command, *args)
File "/usr/local/lib/python3.6/site-packages/redis/client.py", line 2172, in _execute
connection.connect()
File "/usr/local/lib/python3.6/site-packages/redis/connection.py", line 442, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 99 connecting to localhost:6379. Cannot assign requested address.

What is on 6379? And why is it looking for redis when I haven't enabled it as per advice above.
Perhaps I need to explicity disable redis somewhere, or perhaps there is a problem in the container.

OTHER NOTES
On official rabbitmq container the container port 15672 can't be mapped on docker, so I have to remap to 8383. I map 5672 myself because clearly it's needed. And finally the management page doesn't work on 15672 or 8383 anyway - bad for an official container

From what I can read and know, webhooks (which I think is port 9001) is not required for this, webhooks is for external integrations only. So I've not enabled like @Sawrz has above.

I also assume your commentary above about nginx.conf.j2 is not required to enable events, that this nginx configuration is enabled simply via the docker variable EVENTS_ENABLED=True. I have not changed my reverse proxy nginx config, nor anything to do with nginx inside these dockers.

I think you can see why this is hard to fault find right? :)

[blackandred]

Hi,

redis.exceptions.ConnectionError: Error 99 connecting to localhost:6379. Cannot assign requested address.

This error looks simple - there are no permissions for current container user to listn on a port. I don't know why it is trying to listen on it, but we may try to allow it - possibly a setcap is required there.

setcap CAP_NET_BIND_SERVICE=+eip ???

Where ??? is hmm... gunicorn, or python binary or I don't know, you need to try. Add RUN setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary to the new dockerfile, build image inheriting from taiga image and try.

[blackandred]

I think you can see why this is hard to fault find right? :)

Yeah, I already said it somewhere - Taiga Events looks like an abaddon project, it is in bad state - no versioning, alpha release, no responding to issues on github. It is risky. If you will setup this you will be a hero for some people hehe 😉

[marshalleq]

I think it might be easier just to set up redis and make sure it points to a real instance than do whatever you're mentioning above. Or find where it's calling it and remove it. I don't know what setcap does, will have to look that up.

[blackandred]

setcap allows a single binary to increase permissions to allow eg. listening on lower ports or listening at all

…

On Mon, Jun 8, 2020 at 2:27 AM marshalleq ***@***.***> wrote: I think it might be easier just to set up redis and make sure it points to a real instance than do whatever you're mentioning above. Or find where it's calling it and remove it. I don't know what setcap does, will have to look that up. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOAJBSGKSVBT2CNFVNH6S3RVQV67ANCNFSM4MYKFJYQ> .

[marshalleq]

OK so I've actually made some good progress with this this morning. I can't say it's working yet, but there are now no errors and I can see the various components are accepting connections when an event (such as moving a task) occurs.

Bear in mind that I tried a few different things in a different order so some of these may be unnecessary until we pin this down.

Issue 1
So, the first issue I found and the crucial thing that might solve it for others (because maybe I've still got a setting wrong is enabling non localhost connections to RabbitMQ. By default it does not allow this and because all the containers in the original ben Hutchins setup were linked, it would still work. In my docker setup, I have them communicating via IP.

The article that explains this is here, but for the quick attempt you need to do the following:

Map /etc/rabbitmq from within the container to a local location
Edit the rabbitmq.conf file in side there and replace whatever comes after loopback_users.guest = ??? with none.
So that would look like loopback_users.guest = none

Issue 2
There are settings within taiga that are not respecting the environment variables set within the docker container and as such are attempting to connect to localhost (which doesn't work with non-linked containers. I assume @blackandred can look to solve this by fixing the variables? Either way, the settings I found to be a problem and replaced 'localhost' with my IP address were:

/usr/src/taiga-back/settings/celery.py
broker_url = 'amqp://guest:guest@localhost:5672//'
result_backend = 'redis://localhost:6379/0'

Below I also noted celery was enabled, so even though I'm being safe by editing the above celery.py to be correct, I understand it's not needed for events, so have disabled it below in docker.py. In addition I note it's an acceptable variable in local.py so have also disabled it there.

/usr/src/taiga-back/settings/docker.py
Docker.py also needed a change
    BROKER_URL = os.getenv('TAIGA_BROKER_URL', 'amqp://guest:guest@localhost:5672/taiga')
    CELERY_RESULT_BACKEND = os.getenv('TAIGA_REDIS_URL', 'redis://localhost:6379/0').replace('"', '')
    CELERY_ENABLED = False

/usr/src/taiga-back/settings/local.py
CELERY_ENABLED = False

The taiga events container appears to set things correctly, but for completeness the config for that is located in:
/opt/config.json

Through this process I've seen errors from Redis, which are now gone, errors from rabbit which are now gone and errors in taiga, which are now gone. I've actually gone as far as to create a new vhost and a new rabbit user:pass and when doing that, I can still see something is trying to call via guest:guest so there's still undoubtedly another localhost setting to find and change somewhere.

So things are looking much better, but unfortunately I still don't know why events is not moving. Perhaps someone else can use what I've found above to complete this, or perhaps I will find it in the mean time.

Interestingly, I see that my rabbitmq instance is somehow getting communicated from my celery container, even after disabling it where I can. I can see it coming from the IP address in the log. The Celery container is called taiga-celery and I assume something must be calling it by that name in the isolated network I've got as no ports are mapped. Perhaps I need to enable celery on everything then! So confusing.

[marshalleq]

Note to check these ports out: https://stackoverflow.com/questions/25101354/how-may-celery-be-configured-for-port-55672-instead-of-15672-celery-3-1-vs-rab#25101355

[blackandred]

Nice see the progress, I will read this in the evening and reply.

…

On Mon, Jun 15, 2020 at 10:56 PM marshalleq ***@***.***> wrote: Note to check these ports out: https://stackoverflow.com/questions/25101354/how-may-celery-be-configured-for-port-55672-instead-of-15672-celery-3-1-vs-rab#25101355 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOAJBVUQEDVIRTLRHQ3O4LRW2DHJANCNFSM4MYKFJYQ> .

[blackandred]

1. We can add this to FAQ
2. CELERY_ENABLED can be moved to the environment variables of the container, and celery.py should also be configurable via environment variables - I will take a look at it
3. so there's still undoubtedly another localhost setting to find and change somewhere
   That does not sound good, it may be some Taiga default setting that we do not see, I hope they didnt hardcode that 😂

[marshalleq]

Yeah, I began to wonder if I could add localhost to a hosts file (fully knowing that wouldn't actually solve anything permanently), but then quickly realising it's a very bad idea!

BTW I had CELERY_ENABLED=False in my container already - but it obviously wasn't working.

[blackandred]

I added changes to the container, a SNAPSHOT version will be built on quay.io in a minute where you can test it. My time is over for today, tommorow I can test it too.

[blackandred]

root@9a65502f2b3b:/usr/src/taiga-back# find ./ -type f |xargs grep 'localhost'
./tests/unit/test_mdrender.py:    assert result == ["**![smile](http://localhost:8000/static/img/emojis/smile.png)**"]
./tests/unit/test_mdrender.py:        assert result == ('<p>text <a class="mention" href="http://localhost:9001/profile/hermione" '
./tests/unit/test_mdrender.py:        assert result == ('<p>text <a class="mention" href="http://localhost:9001/profile/luna.lovegood" '
./tests/unit/test_mdrender.py:        assert result == ('<p>text <a class="mention" href="http://localhost:9001/profile/super-ginny" '
./tests/unit/test_mdrender.py:        expected_result = '<p><strong><a class="reference user-story" href="http://localhost:9001/project/test/us/1" title="#1 test">&num;1</a></strong></p>'
./tests/unit/test_mdrender.py:        expected_result = '<p><strong><a class="reference issue" href="http://localhost:9001/project/test/issue/2" title="#2 test">&num;2</a></strong></p>'
./tests/unit/test_mdrender.py:        expected_result = '<p><strong><a class="reference task" href="http://localhost:9001/project/test/task/3" title="#3 test">&num;3</a></strong></p>'
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/test\" title=\"test\">test</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/test\" title=\"test\">test</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/test-page\" title=\"test page\">test page</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/testpage\" title=\"TestPage\">TestPage</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/test\" title=\"custom\">custom</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a class=\"reference wiki\" href=\"http://localhost:9001/project/test/wiki/wiki_page\" title=\"wiki page\">wiki</a></p>"
./tests/unit/test_mdrender.py:    expected_result = "<p><a href=\"http://localhost:9001/project/test/\">test project</a></p>"
./tests/integration/test_mdrender.py:    expected_result = "<p><strong><a class=\"mention\" href=\"http://localhost:9001/profile/user1\" title=\"test name\">@user1</a></strong></p>"
./tests/integration/test_mdrender.py:    expected_result = "<p><strong><a class=\"mention\" href=\"http://localhost:9001/profile/user1_text_after_dash\" title=\"test name\">@user1_text_after_dash</a></strong></p>"
./tests/integration/test_notifications.py:    id = '<test/message@localhost>'
./tests/integration/test_importers_trello_api.py:    assert response.data['url'] == "https://trello.com/1/OAuthAuthorizeToken?oauth_token=token&scope=read,write,account&expiration=1day&name=Taiga&return_url=http://localhost:9001/project/new/import/trello"
./tests/integration/test_importers_github_api.py:    url = reverse("importers-github-auth-url")+"?uri=http://localhost:9001/project/new?from=github"
./tests/integration/test_importers_github_api.py:    assert response.data['url'] == "https://github.com/login/oauth/authorize?client_id=&scope=user,repo&redirect_uri=http://localhost:9001/project/new?from=github"
./tests/factories.py:    url = "http://localhost:8080/test"
./tests/factories.py:    url = "http://localhost:8080/test"
./settings/common.py:    "api": {"domain": "localhost:8000", "scheme": "http", "name": "api"},
./settings/common.py:    "front": {"domain": "localhost:9001", "scheme": "http", "name": "front"},
./settings/common.py:MEDIA_URL = "http://localhost:8000/media/"
./settings/common.py:STATIC_URL = "http://localhost:8000/static/"
./settings/celery.py:broker_url = 'amqp://guest:guest@localhost:5672//'
./settings/celery.py:result_backend = 'redis://localhost:6379/0'
./settings/local.py.example:#       "domain": "localhost:8000",
./settings/local.py.example:#       "domain": "localhost:9001",
./settings/local.py.example:#EMAIL_HOST = 'localhost'
./settings/docker.py:TAIGA_HOSTNAME = os.getenv('TAIGA_HOSTNAME', 'localhost')
Binary file ./settings/__pycache__/common.cpython-36.pyc matches
Binary file ./settings/__pycache__/docker.cpython-36.pyc matches
Binary file ./settings/__pycache__/celery.cpython-36.pyc matches
./taiga/base/utils/urls.py:def build_url(path, scheme="http", domain="localhost"):
Binary file ./taiga/base/utils/__pycache__/urls.cpython-36.pyc matches
root@9a65502f2b3b:/usr/src/taiga-back# 

root@9a65502f2b3b:/usr/src/taiga-back# find ./ -type f |xargs grep '127.0.0.1'
./tests/unit/test_utils.py:    "http://127.0.0.1",
./tests/unit/test_common_throttle.py:    settings.REST_FRAMEWORK['DEFAULT_THROTTLE_WHITELIST'] = ["127.0.0.1"]
./tests/unit/test_common_throttle.py:    request.META["REMOTE_ADDR"] = "127.0.0.1"
./tests/unit/test_common_throttle.py:    settings.REST_FRAMEWORK['DEFAULT_THROTTLE_WHITELIST'] = ["127.0.0.1"]
./settings/common.py:# EVENTS_PUSH_BACKEND_OPTIONS = {"url": "//guest:[email protected]/"}

[blackandred]

https://travis-ci.org/github/riotkit-org/docker-taiga/builds/699199688#L6656

[marshalleq]

So, from the changes above, the CELERY_ENABLED=False should work, if it applies in all the right places. When you say CELERY is also configurable from the container, is that documented anywhere? Sorry, just not sure what that means. Thanks for doing this - baby steps!

[blackandred]

Sorry, no docs until we will have it clear how it works. Currently I attempt to help you and I add what you need, when you will reach a point that it works, then we can write docs I think.

[blackandred]

Currently the only one documentation are the commits, later we need to extend README.

52c180e
6af1870

[marshalleq]

Yeah, I wasn't expect those kind of docs, was just looking for any record of what making celery configurable meant as that could be read in many ways. I'm trying to read your commits, but not being a developer, I'm not going to understand the change as quickly as the person whom made it. :)

[blackandred]

Sorry, I didn't update README 😉

Those are new environment variables:

# Enables Celery support
- CELERY_ENABLED # (default: false)

# Serializer type supported by Taiga at Celery
- CELERY_SERIALIZER_TYPE # (default: pickle)

[blackandred]

I see this issue is still open.

So, there was a recently change in this area:
#42

And also the Taiga Events project is recently alive, I will take a look what changed in the Taiga Events recently.

[blackandred]

It seems that taiga-front and taiga-events was replaced by https://github.com/taigaio/taiga-front-next
Possibly it can resolve this issue at all without having to setup additionally a server?

[marshalleq]

Would be good if it did - I do see their development has come back to life for a bit. Is this what 5.5.0-D1.4 is? I'm running the 5.0 version. Tried updating straight to it but it doesn't like it.

[marshalleq]

So Taiga 6 is out with an official docker. I've been trying to get it going to understand what we can do about this, so far no dice.

[marshalleq]

This new documentation is actually quite insightful: https://taigaio.github.io/taiga-doc/dist/setup-production.html#setup-prod-with-docker

[blackandred]

@marshalleq Hi, I think we can move to a separate issue, and consider if a separate container needs still to be maintained.

In this month I will be probably upgrading privately to Taiga 5 (not 6, there is no Taiga 6 😁).

[blackandred]

Ah, ok, it's 6'th version 👍

[marshalleq]

Back now from a hiatus from needing Taiga. We're going to be having a larger team this time, so this is going to get super annoying if it's not working. I suspect I'm going to have to go to the official docker, but it's so unneccessarily complicated I feel like I'm wasting precious time on the wrong thing. What would be better would be to just get it running here.