Usage in GitLab not working

Hi,
I see issues such as https://github.com/testcontainers/testcontainers-python/issues/43, https://github.com/testcontainers/testcontainers-python/issues/25, https://github.com/testcontainers/testcontainers-python/pull/154 and the gitlab-ci.yml in the gitlab branch indicating that testcontainers should be working in the GitLab CI. Can someone confirm if this is still true? Looks like the last testrun on the testcontainers-python-project was two years ago (https://gitlab.com/tillahoffmann/testcontainers-python/-/pipelines/140551456).
I use a file very similar config to the on in the gitlab branch (also tried all variations I can think of)
variables:
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: ""
    DOCKER_HOST: "tcp://docker:2375"

services:
- name: docker:dind
  command: ["--tls=false"]

tests_testcontainer:
  image: "python:3.9"
  script:
    - pip install pytest~=7.0.1 testcontainers[kafka]~=3.5.3
    - pytest --log-cli-level=debug -s -v test_testcontainers.py

With this test
import logging
from testcontainers.kafka import KafkaContaine
LOG = logging.getLogger(__name__)

def test_containers():
    LOG.info("test_containers 1")
    with KafkaContainer() as kafka_server:
        LOG.info("test_containers 2")
        assert kafka_server
        LOG.info("test_containers 3")
    LOG.info("test_containers 4")

But it hangs on the with-line waiting for the container to be created. It looks like it's communicating fine with the docker daemon but for some reason nothing more happens. Creating a container using the docker cli tool works fine when done in .gitlab-ci.yml or with subprocess inside python.
Does someone understand what's goning on? Any help is greatly appreciated.

Expand for test log output
$ pytest --log-cli-level=debug -s -v test_testcontainers.py
============================= test session starts ==============================
platform linux -- Python 3.9.12, pytest-7.0.1, pluggy-1.0.0 -- /usr/local/bin/python
cachedir: .pytest_cache
rootdir: /builds, configfile: pyproject.toml
collecting ... collected 1 item
test_testcontainers.py::test_containers
-------------------------------- live log call ---------------------------------
INFO     test_testcontainers:test_testcontainers.py:9 test_containers 1
DEBUG    docker.utils.config:config.py:21 Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
DEBUG    docker.utils.config:config.py:28 No config file found
DEBUG    docker.utils.config:config.py:21 Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
DEBUG    docker.utils.config:config.py:28 No config file found
DEBUG    urllib3.connectionpool:connectionpool.py:228 Starting new HTTP connection (1): docker:2375
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /version HTTP/1.1" 200 811
Pulling image confluentinc/cp-kafka:5.4.3
INFO     testcontainers.core.container:container.py:51 Pulling image confluentinc/cp-kafka:5.4.3
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "POST /v1.41/containers/create HTTP/1.1" 404 57
DEBUG    docker.auth:auth.py:39 Looking for auth config
DEBUG    docker.auth:auth.py:41 No auth config in memory - loading from filesystem
DEBUG    docker.utils.config:config.py:21 Trying paths: ['/root/.docker/config.json', '/root/.dockercfg']
DEBUG    docker.utils.config:config.py:28 No config file found
DEBUG    docker.auth:auth.py:240 Looking for auth entry for 'docker.io'
DEBUG    docker.auth:auth.py:251 No entry found
DEBUG    docker.auth:auth.py:56 No auth config found
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "POST /v1.41/images/create?tag=5.4.3&fromImage=confluentinc%2Fcp-kafka HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/images/confluentinc/cp-kafka:5.4.3/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "POST /v1.41/containers/create HTTP/1.1" 201 88
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "POST /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/start HTTP/1.1" 204 0
Container started: 8dbc8cbfbc
INFO     testcontainers.core.container:container.py:62 Container started: 8dbc8cbfbc
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1650
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1650
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "PUT /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/archive?path=%2F HTTP/1.1" 200 0
Waiting to be ready...
INFO     testcontainers.core.waiting_utils:waiting_utils.py:46 Waiting to be ready...
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1650
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1650
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1641
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1642
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/8dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7/json HTTP/1.1" 200 None
DEBUG    urllib3.connectionpool:connectionpool.py:456 http://docker:2375 "GET /v1.41/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22id%22%3A+%5B%228dbc8cbfbc2fd063d21fa1725536ab766372580f829415f0748177a2a78952e7%22%5D%7D HTTP/1.1" 200 1646
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-closed
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name connections-created
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name select-time
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name io-time
DEBUG    kafka.client:client_async.py:374 Initiating connection to node bootstrap-0 at <IP_ADDRESS>:49153
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name request-latency
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-sent
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.bytes-received
DEBUG    kafka.metrics.metrics:metrics.py:156 Added sensor with name node-bootstrap-0.latency
DEBUG    kafka.conn:conn.py:368 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 None]>: creating new socket
DEBUG    kafka.conn:conn.py:374 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <disconnected> [IPv4 ('<IP_ADDRESS>', 49153)]>: setting socket option (6, 1, 1)
INFO     kafka.conn:conn.py:380 <BrokerConnection node_id=bootstrap-0 host=<IP_ADDRESS>:49153 <connecting> [IPv4 ('<IP_ADDRESS>', 49153)]>: connecting to <IP_ADDRESS>:49153 [('<IP_ADDRESS>', 49153) IPv4]
INFO     kafka.conn:conn.py:1205 Probing node bootstrap-0 broker version
ERROR: Job failed: execution took longer than 3m0s seconds

Testing on gitlab CI is rather difficult because of this issue. In short, gitlab cannot run CI on forks which means every change would first have to be pushed onto a branch in the main repository. I don't expect to pick it up again until the issue is resolved.

I modified the test to have greater control over the container setup.
import logging
import socket
import time

from kafka import KafkaConsumer
from kafka.errors import KafkaError, NoBrokersAvailable, UnrecognizedBrokerVersion
from testcontainers.kafka import KafkaContainer

LOG = logging.getLogger(__name__)

def test_containers():
    kc = KafkaContainer()
    command = f'sh -c "while [ ! -f {KafkaContainer.TC_START_SCRIPT} ]; do sleep 0.1; done; bash {KafkaContainer.TC_START_SCRIPT}"'
    kc.with_command(command)
    super(type(kc), kc).start()
    kc.tc_start()
    if True:
        my_connect(kc)
    else:
        time.sleep(20)
        socket_test(kc)

def socket_test(kc):
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(60)
        s.connect((kc.get_container_host_ip(), int(kc.get_exposed_port(kc.port_to_expose))))
    except Exception:
        LOG.exception("socket error")

TRANSIENT_EXCEPTIONS = (
    TimeoutError,
    ConnectionError,
    UnrecognizedBrokerVersion,
    NoBrokersAvailable,
    KafkaError,
    ValueError,
)

def my_connect(kc):
    for i in range(20):
        try:
            bootstrap_server = kc.get_bootstrap_server()
            LOG.info("my_connect bootstrap_server: %s", bootstrap_server)
            consumer = KafkaConsumer(group_id="test", bootstrap_servers=[bootstrap_server])
            if not consumer.topics():
                raise KafkaError("Unable to connect with kafka container!")
            return
        except TRANSIENT_EXCEPTIONS:
            LOG.exception("my_connect failed")
        time.sleep(2)

When my_connect is called the error is
ERROR    test_testcontainers:test_testcontainers.py:172 my_connect failed
Traceback (most recent call last):
  File "/builds/dkinternal/heimdall-be/test_testcontainers.py", line 166, in my_connect
    consumer = KafkaConsumer(group_id="test", bootstrap_servers=[bootstrap_server])
  File "/usr/local/lib/python3.9/site-packages/kafka/consumer/group.py", line 356, in __init__
    self._client = KafkaClient(metrics=self._metrics, **self.config)
  File "/usr/local/lib/python3.9/site-packages/kafka/client_async.py", line 244, in __init__
    self.config['api_version'] = self.check_version(timeout=check_timeout)
  File "/usr/local/lib/python3.9/site-packages/kafka/client_async.py", line 927, in check_version
    raise Errors.NoBrokersAvailable()
kafka.errors.NoBrokersAvailable: NoBrokersAvailable

socket_test gives a timeout
ERROR    test_testcontainers:test_testcontainers.py:62 socket error
Traceback (most recent call last):
  File "/builds/dkinternal/heimdall-be/test_testcontainers.py", line 55, in socket_test
    s.connect((kc.get_container_host_ip(), int(kc.get_exposed_port(kc.port_to_expose))))
socket.timeout: timed out

I've extracted the Kafka container logs and found no issues. The listening IP and port listed in the log are the same as generated by testcontainers' get_bootstrap_server. It appears to me that the test container and the Kafka container cannot reach each other.
I tried setting FF_NETWORK_PER_BUILD but it made no difference. I have the feeling it only affects services listed in .gitlab-ci.yaml.

This gitlab runner issue seems relevant. Some conflicting reports on whether it works or not. https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3251

fwiw - we run some of our test containers on gitlab-ci with the 'services'. This will delegate launching containers to gitlab, which usually works fine. That means that your test setup on ci will be slightly different from the one that you execute on your dev machine, which is not always what you want. But it worked fine for our case and caused no major trouble.
Maybe that helps you to solve your problem. The docs are here: https://docs.gitlab.com/ee/ci/services/

I just got the PostgreSQL container running it GitLab using Docker-in-Docker and the following fix for the container:
class FixedPostgresContainer(PostgresContainer):
    """
    This class fixes a bug that the PostgresContainer does not start if docker runs on a dedicated host
    (DOCKER_HOST is set).
    See: https://github.com/testcontainers/testcontainers-python/issues/217
    """
    def get_connection_url(self, host=None) -> str:
        if host is None:
            host = self.get_docker_client().host()
        return super().get_connection_url(host)

Then just use FixedPostgresContainer instead of PostgresContainer.
For me the container was trying to connect to Postgres on a local socket and did not respect the DOCKER_HOST variable.
Maybe it would make sense to add this fix to the postgres container.

Interesting, @jakobbraun. Do you know why this resolves the issue? It seems to me like the fixed version should give the same result. In particular, the call sequence is as follows (in the unfixed version).
https://github.com/testcontainers/testcontainers-python/blob/b4ccb972e9edcc2289cce7fb66524d3f4865b7fb/testcontainers/postgres.py#L56-L62
So host is passed as is (still None) to ...
https://github.com/testcontainers/testcontainers-python/blob/b4ccb972e9edcc2289cce7fb66524d3f4865b7fb/testcontainers/core/generic.py#L38-L50
Because host is still None we end up calling ...
https://github.com/testcontainers/testcontainers-python/blob/b4ccb972e9edcc2289cce7fb66524d3f4865b7fb/testcontainers/core/container.py#L84-L102
But that also returns self.get_docker_client().host(), the same as the fixed version. Any idea what I'm missing?

Ok, now I found the time to take a clother look. (Don't wonder that I changed the github account. Now it's my company account but still me.)
You're right. I jsut accidentially fixed the problem.
The line you mentioned is also perfectly fine. The issue is the if inside_container() condition: This is true since we are in a contaiener.  Insdie the condition we then return something else then the value of host.
My "fix" did not use this method and therefore did work.
I just noticed that the code inside the condition does not fit to the comment.
The comment sais:

otherwise fall back to detected host  address

But the code falls back on the gateway_ip .

Would you mind trying this snippet just to check that we have a valid host variable?
class FixedPostgresContainer(PostgresContainer):
    """
    This class fixes a bug that the PostgresContainer does not start if docker runs on a dedicated host
    (DOCKER_HOST is set).
    See: https://github.com/testcontainers/testcontainers-python/issues/217
    """
    def get_connection_url(self, host=None) -> str:
        if host is None:
            host = self.get_docker_client().host()
            assert host
        return super().get_connection_url(host)

For what it's worth, the fix @jakobbraun suggested also seems to work for the MySqlContainer:
class FixedMySqlContainer(MySqlContainer):
    def get_connection_url(self, host=None) -> str:
        if host is None:
            host = self.get_docker_client().host()
        return super()._create_connection_url(dialect="mysql+pymysql",
                                              username=self.MYSQL_USER,
                                              password=self.MYSQL_PASSWORD,
                                              db_name=self.MYSQL_DATABASE,
                                              port=self.port_to_expose,
                                              host=host)

Also tested this locally, that seems to work fine too.
Building further upon what @hpsjakob said:

Ok, now I found the time to take a clother look. (Don't wonder that I changed the github account. Now it's my company account but still me.) You're right. I jsut accidentially fixed the problem. The line you mentioned is also perfectly fine. The issue is the if inside_container() condition: This is true since we are in a contaiener. Insdie the condition we then return something else then the value of host.

IMO, this seems exactly right. Some test in Gitlab show that self.get_docker_client().host() is going to resolve to "docker" when "DOCKER_HOST" is set to "tcp://docker:2375". The gateway and the bridge ip of the started container are always going to differ from the ip of the "docker:dind" service, given that the service is started as a separate container.
I might be oversimplifying here, but isn't a check for whether "DOCKER_HOST" is set enough for determining at least the docker-in-docker situations?

@tillahoffmann , tested functioning in Gitlab with the workaround present in the latest version. Seems like it is resolved, and this issue can be closed.

Nice, thanks for the update.


cargo update: Don't fetch from the remote repo if the revision is already present locally

This makes cargo update much faster when there are many git deps in a repo and they're already
cached locally.
There was an existing check for this, but it didn't quite hit all cases.
The code looked like this:
        let (db, actual_rev) = match (self.locked_rev, db) {
            (Some(rev), Some(db)) if db.contains(rev) => (db, rev),
            (None, Some(db)) if self.config.offline() => {
                let rev = db.resolve(&self.manifest_reference)?;
                (db, rev)
            }
            (locked_rev, db) => self.remote.checkout(),
        };

The problem was that when locked_rev.is_none() && db.is_some() and --offline wasn't passed,
cargo would skip the db.resolve() check, and issue a fetch from the remote even if it wasn't
necessary.
This changes the db.resolve() check to happen even in online mode.
This brings cargo update down from 53 to 6 seconds for me on a codebase with 10+ git dependencies.

r? @alexcrichton
(rust-highfive has picked a reviewer for you, use r? to override)

It's very strange because git rev-parse HEAD from the same directory works fine:

Oh, I found the issue - rev-parse from the *checkoutworks fine, butrev-parsefrom the directory in~/.cargo/git/db/crate-hash` doesn't, because it's a bare repo. I need to check it against the commit for the checkout somehow.

Oh interesting, there's already a check for this at https://github.com/rust-lang/cargo/blob/ba9f2f80dd439bf38e81dcf907c1c06cfe9bf371/src/cargo/sources/git/source.rs#L114-L123 - I think I can move that into fetch so that it's cached consistently.

Ah wait no, cargo update already goes through that codepath, so it should be hitting that check already. The slowdown I was hitting is when locked_rev is None, because https://github.com/rust-lang/cargo/blob/ba9f2f80dd439bf38e81dcf907c1c06cfe9bf371/src/cargo/sources/git/source.rs#L128-L133 only gets hit when running in offline mode. If it checked db.resolve whenever db.is_some() I think it would fix my issue.

I am not following this super closely and it seems like this is rapidly changing. I wanted to say though that as a heads up the premise of this PR I think is flawed. A reference to something like a branch cannot check to see if there's a local copy since we need to check the remote to see if there's a more up-to-date version. The only case we can skip the remote update is if we have a locked git sha and that's already local. Just because we have refs/heads/main locally doesn't mean it's up-to-date.

The only case we can skip the remote update is if we have a locked git sha and that's already local. Just because we have refs/heads/main locally doesn't mean it's up-to-date.

Ok, I can ensure this only happens when the revision is a locked sha and not a branch. The reason I opened this in the first place though is because cargo was updating the remote even when it's locked to a sha.

A git revision can be a tag or sha or anything. I don't think we can simply search it in the local db. Especially when it cannot be parsed as a commit object.
For instance, the rev is a tag and chances are that the remote tag has been updated to point to another commit but our local database is still stale.

Maybe something like this to check if the rev is a commit sha
https://github.com/rust-lang/cargo/pull/10079/files#diff-0e22d3c91f7eac28d92382b445103b421ef842eef760bdc1885be073117f3e9dR1090-R1092

I found this doesn't actually fix my problem. Sorry for the noise.


Always check the sequence when adding to the transaction queue

High Level Overview of Change
#3271 made a change to transaction processing in the Transaction Queue (TxQ) for transactions that are being considered for queuing, to validate the sequence/ticket on the TxQ side, and bypass the sequence check in the Transactor. Because the sequence didn't need to be checked, it was thought no longer necessary to "bump" the account's sequence number if there were multiple transactions queued, so that code was removed. Unfortunately, there are cases in OfferCreate and OfferCancel where the OfferSequence field is checked against the account sequence number. If the offer to be cancelled is in the queue, and the account sequence doesn't get bumped, then when the transaction is processed it will return temBAD_SEQUENCE from preflight. Worse, because that's a tem code, the transaction is cached as "bad" and won't be reconsidered unless the transaction is in a validated ledger (fortunately, no validators are currently running 1.7, so that's fine).
This PR accomplishes three separate things, left for now as three separate commits. When it's ready to be merged, we may want to squash them into a single commit, or only squash the first two (more on that below).

The first commit adds a unit test reproducing the problem. It also add a new engine result code terTICKET, which indicates that the transaction can't be processed until the ticket it refers to is consumed. No code outside of the test refers to this new code, so I think it's safe.
Is the actual fix. First, and most importantly, it changes the TxQ logic to go back to the old behavior of "bumping" the account's sequence number, and always checks the sequence in preflight. Second, it checks all transactions that refer to another transaction using its sequence number (including OfferCreate, OfferCancel, EscrowFinish, and EscrowCancel, but the check is generalized to all transactions that have the right fields) for an existing ticket in the ledger for that sequence. If a pending ticket is found, the new terTICKET result is returned. As long as this PR is included in 1.7 release, this does not need a new amendment because ticket functionality is new with 1.7 and without the TicketBatch amendment, tickets can not exist in the ledger. It also adds a STObject::at() which functions identically to STObject::operator[], and splits the TxQ unit tests into two suites to improve speed.
This one is a little more optional. The original symptom of the problem was because temBAD_SEQUENCE was returned by preclaim based on data in the ledger. IMHO, that check can and should be done in preflight based just on the data in the transaction. This adds a new amendment fixOfferSequence. If the amendment is enabled and the OfferSequence is not smaller than the Sequence, preflight returns temBAD_SEQUENCE. This is the exact same behavior, only the check is sooner in the process. I only put it behind an amendment because they changed order may have some unexpected consequences (and it did require updating a unit test). I still think it's useful because catching this malformation earlier will save time and resources.

Type of Change

[X] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] Tests (You added tests for code that already exists, or your new feature included in this PR)

Test Plan
Test the temBAD_SEQUENCE fix
With version 1.6.0 and the version that contains this PR.

Get enough transactions into the ledger to cause fee to escalate.
Submit several OfferCreate and OfferCancel transactions with low fees (e.g. 10 drops) in short order (before the ledger closes). Each transaction except the first should cancel the prior. The first must be an OfferCreate. The others can be some kind of mix.
Verify that all the transactions return terQUEUED.
Verify that all the transactions eventually make it into a validated ledger.

With a beta of 1.7 before this is merged, all of the transactions submitted after the first will return temBAD_SEQUENCE.
Test terTICKET

Enable the "TicketBatch" amendment.
Create an arbitrary number of tickets using TicketCreate.
Submit an OfferCreate, OfferCancel, EscrowFinish, and/or EscrowCancel that use the sequence number of one of the just created tickets as the OfferSequence. For the escrow transactions, you can either use the same account in the Owner field, or even better, submit those from an account different than the one that created the tickets and use the ticket creator as Owner.
All of the transactions in step 2 should return terTICKET.
Submit any kind of transaction to consume the tickets that the transactions from step 2 referred to. Some of them can be EscrowCreate, but that is not necessary.
Resubmit all of the transactions from step 2.
All of the offer-related transaction should succeed. The escrow-related transactions should only succeed if a corresponding escrow was created in step 4, otherwise, they should return tecNO_TARGET.

Test fixOfferSequence

Without the amendment, submit an OfferCreate or OfferCancel where the Sequence field is smaller or equal to the OfferSequence field. Note that OfferSequence is optional in the OfferCreate transaction. It will return temBAD_SEQUENCE.
With the amendment, submit an OfferCreate or OfferCancel where the Sequence field is smaller or equal to the OfferSequence field. Note that OfferSequence is optional in the OfferCreate transaction. It will also return temBAD_SEQUENCE.

Future Tasks
Only preflight should return tem engine results. It should not require referring to the ledger (except the Rules which is provided to preflight) to determine if a transaction is properly formed. Similar to the NotTEC type, consider a NotTEM type that is returned from preclaim and doApply. Once the fixOfferSequence is enabled, it should be safe to remove the check in preflight that first triggered this issue (or return a different result). Any other tem codes returned by preclaim or doApply will probably need similar amendments.

This change is

Rebased on to 1.7.0-b3

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@0b4e34b). Click here to learn what that means.
The diff coverage is n/a.

I spent some time looking at the bug that tickets introduced.  I compared the value of the messed up error check against the added complexity in the TxQ.  Given that comparison, I'd like to propose an alternative approach to a fix.
The OfferSequence validation on canceled offers is pretty rudimentary.  It checks for zero (which would never be valid) and it checks for the OfferSequence being less than the account root Sequence.  This validation only acts as a rudimentary sanity check.  There has never been any validation that the offer being canceled is now or ever was in the ledger.  Canceling an offer that is not in the ledger is handled as a successful transaction.
My suggestion is that we remove the rudimentary validation.  The rudimentary validation used to be cheap.  It's no longer cheap because it requires the TxQ to jump through hoops for every transaction the TxQ validates (not just those that cancel offers).  I think those rudimentary checks no longer hold up to a cost/benefit analysis.
I did an audit and, beyond offer canceling, there's one additional transaction that is sensitive to the TxQ not having the right account root Sequence during preclaim: that's AccountDelete.  That check is important, but it returns a tec code.  So that check can be moved from preclaim to doApply with no loss of efficiency.
Here's a commit that shows the alternative I'm proposing: https://github.com/scottschurr/rippled/commit/b5c793200b03c77983f8af364dadb5fbad7649fb
Thoughts?  Thanks.

@scottschurr Thanks for thinking this through and going through the effort to come up with an alternative solution. I don't think it's the way to go, though. I have a few reasons:

I don't think the changes I made to TxQ are all that complicated or have it jumping through hoops. Basically, all that changed is that TxQ now calls nextQueuableSeqImpl earlier and unconditionally, changes the sequence (a uint32) on an SLE that is already loaded, and removes the code that bypasses the sequence check in the Transactor. That has the effect of making the validation cheap again. It's also more resilient - if new functionality is introduced or changed that depends on account sequence numbers, the transactor doesn't have to know or care under what circumstances it's being invoked under.
Without your new amendment, fixOfferCancelSeqErr, being enabled, the broken behavior will still exist in 1.7, and there's no telling how long it'll take to get that enabled. The reason this behavior is so bad is https://github.com/ripple/rippled/blob/develop/src/ripple/app/misc/NetworkOPs.cpp#L1344-L1345 - The transaction is marked as bad and will not be considered by that node again unless it's in a proposed transaction set. And if the validators are all running 1.7, it may not be in any proposed set.
My changes fix the bug right out of the gate, no amendment required. The amendment I introduced really is optional, and simply does the same check - basically preserving the same Transactor behavior - earlier in the process.
As for terTICKET, which you propose not adding, that's not a core part of the bug fix, and it could be removed without breaking transaction processing. It would make the potential results of two related transactions (one consuming a ticket to create a ledger entry, the other operating on that ledger entry - this could include Offers, but also Escrows) dependent on the order in which the transactions are executed, but the validators will choose one order and everything will be fine in terms of the ledger. I imagine that may cause some users to get unexpected results if an order they thought they had cancelled was still on the books. Ordering has always a potential issue with tickets, but in most cases it didn't really matter. Some general things might be affected, like not having enough XRP to pay fees, but that can always be an issue. The difference IMHO is that these two transactions are explicitly linked, so it doesn't really make sense to allow the cancel/finish to process before the create.


Trademark Issue

I suspect you may want to rename this project.  I grant you that the name is clever and I wish you nothing but the best of luck.  But the fact that Dymola is trademarked by a large company with very deep pockets would make me hesitant to give a project, which is very much in a related area, a name that is only one letter difference.
The thing is, the nature of trademark law is such that they have almost no choice but to step in (if they find out about this project) because they can lose their trademark if they don't take steps to defend it.  So if they do come knocking, just be aware that it isn't (necessarily) that they are trying to be difficult.

@xogeny Thanks for the heads up. I'm fine with renaming, we can start thinking up some ideas.
pymodelica is already used unfortunately.

pymelica
pymodla
pymolica
pymolica <-- kind of like this

Prior to discovering pymola, we considered calling our Modelica-to-CasADi project 'moca'.

'mosym' also sounds nice imo.

A +1 from me for pymolica.
I suggest not waiting too long with a renaming, as the impact of doing so would only get larger. Preferably we would do it as soon as possible.

Agree we should do this asap.
pymolica sounds nice but is easy to confuse with pymodelica for sloppy readers like myself.

Any objections to running with pymoca?   Seems short, one letter change, and can be generalized to Python MOdelica -> Computer Algebra system

+1 for pymoca

@jbaayen @jackvreeken pymoca work for you?

Yep, fine by me. Moca/mocha is used by everyone and their dog (but no one in the Modelica world afaik), so I doubt we would have a trademark issue there.

OK, should I go ahead an change the orgnaization and project name? We can worry about refactoring the code after that.

Rename complete, I created a new branch for rename of the source code to see if it broke anything.


Utilize Cache Headers

Right now the caching solution from what I can see has no TTL. To avoid over-caching and ignoring server-defined headers, why not make use of https://github.com/gregjones/httpcache?

@asciimoo I sorta need this now so want to start working on a PR ,do you have any opposition to me pulling in the http cache  lib mentioned in the original request. I did a few quick tests locally and it looks like it should do the job and allow the library to be a bit more flexible as well.


Turn off option for Additional Key Bindings

Feature Request
It would be nice if there was a way to easily opt out via a setting(s) of the additional key bindings found in https://github.com/vscode-neovim/vscode-neovim#-bindings. Some folks don't use the default Vim keybindings which conflict with these additions.

@theol0403 Do you know why noremap was picked over map? Could simply converting all bindings to map be sufficient enough as it would allow anybody to unbind those to <nop>?

@martin-braun I'm not sure what you mean, you should already be able to unbind those manually. I think OP was asking if it could be disabled at the source.

I guess your purpose is to disable the keybindings in vscode, not the mappings in vim.


ImportError: No module named 'BlynkTimer'

BlynkTimer seems to be broken somehow, cannot import it.
pi@raspberrypi:~/hytta $ python3 main.py
    ___  __          __
   / _ )/ /_ _____  / /__
  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/ for Python v0.2.0 (Linux)

Traceback (most recent call last):
  File "main.py", line 2, in <module>
    from BlynkTimer import BlynkTimer
ImportError: No module named 'BlynkTimer'

Sorry about that! I forgot to add the module to setup.py.
Just opened a tiny PR to fix it.

Awesome, thanks!

I'm also having the same issue, any way to fix it?

@vitormhenrique Seems that this repo is no longer being maintained. I would checkout lib-python, which is an actively maintained Blynkkk owned repo for python.
Otherwise, you can simply download the BlynkTimer.py file and upload it to your pyboard under /lib/BlynkTimer.py. There it will automatically be picked up by micropython and you can import it as so: from BlynkTimer import timer

I actually was using the other library and got the same error! just realized that!

@vitormhenrique Haha, can't blame you, there is a bit of confusion with two repos like this. On the other repo, the timer class is named Timer so it should be from blynktimer import Timer -- see here
if that doesn't fix your problem however, I would open an issue on (lib-python)[https://github.com/blynkkk/lib-python].

Thanks!
I noticed that their setup.py does not include the blynktimer.
py_modules=['blynklib']
I already forked the repo and fixed.
Thanks for the help!
 On the other
repo, the timer class is named Timer so it should be from blynktimer
import Timer -- see here
https://github.com/blynkkk/lib-python/blob/master/TIMERS.md
if that doesn't fix your problem however, I would open an issue on
(lib-python)[https://github.com/blynkkk/lib-python].
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vshymanskyy/blynk-library-python/issues/34?email_source=notifications&email_token=AA6ITF6YD6LBYICWNKNOIUTP4LLJXA5CNFSM4HBRVZ2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYSFJGA#issuecomment-505697432,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6ITF3YXMYEAHMYU7YAEC3P4LLJXANCNFSM4HBRVZ2A
.

I got it fixed !!!!!!!!!
copy the  BlynkLib in the same folder where your code is. It should fix the problem
NOTE: This problem is happening because while installing bylnk by default python2 is used but for other application we are using python3 where the library is not getting copied.

This steps are for only new installed raspbian :
Suggested to follow :
Step 1 : With the new install raspbian on PI
Go to the link
https://learn.sparkfun.com/tutorials/python-programming-tutorial-getting-started-with-the-raspberry-pi/configure-your-pi
follow along from
Use Python 3
Till the end
Step 2:
install the blynk now and it should work

Still any issue please write to be directly at<EMAIL_ADDRESS>will help you ASAP(FREE).


Open TFS source code file in VS Code

I am trying to checkout the file in VS Code but getting below error.
Error: spawn "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe" ENOENT

I got to resolve this. I was adding double quotes around the path. I removed quotes and it worked for me. Thanks


x/crypto/{blake2b,blake2s}: implement encoding.BinaryMarshaler and encoding.BinaryUnmarshaler

It is often useful to be able to copy the internal state for blake2b, such as if you want to compute Blake2b(msg || tag1) and Blake2b(msg || tag2), and you want to avoid double-computing what results from updating msg.
I've added a clone method to do this here. This is an improvement that can't be made in applications using the library, since the digest struct isn't exported.
Since the publicly visible interface for digest is hash.Hash, I made the method for cloning func Clone(h hash.Hash) (*digest, error) instead of func (d *digest) Clone (*digest).
This could alternatively be added as a method that everything which implements the hash.Hash interface must implement, since there have been requests for this before. (Link 1, Link 2)

I don't think adding a custom Clone function to every hash function is a proper solution.
I think the idea of this proposal is related #20573 - However there is a fundamental problem using encoding.BinaryMarshaler and encoding.BinaryUnmarshaler for functions that can be used as MAC (like BLAKE2, SHA-3, HMAC):

Either we serialize and store the secret key which is IMO not a good idea because of possibly  leaking sensitive information (accidentally).
Or we exclude the secret key which leads to the following problem:key := make([]byte, 32) // secret key
b2, _ := blake2b.New(key)

    var err error
var b2State []byte
if marshaler, ok := b2.(encoding.BinaryMarshaler); ok {
	b2State, err = marshaler.MarshalBinary()
	if err != nil {
		fmt.Println(err)
		return
	}
}

if unmarshaler, ok := b2.(encoding.BinaryUnmarshaler); ok {
	err = unmarshaler.UnmarshalBinary(b2State)
	if err != nil {
		fmt.Println(err)
		return
	}
}

b2.Reset() // what should happen here
fmt.Println(hex.EncodeToString(b2.Sum(nil))) // what should be printed

BTW: adding a function to hash.Hash is not possible - backward compatibility.
/cc @FiloSottile

Thanks for explaining the situation with encoding.BinaryMarshaler, I didn't realize that existed. That solves the problem I was having (whereas blake2x wouldn't since I needed compatibility with blake2b hashes in another language).
I agree, adding a custom clone method to every hash is not a good solution. For the HMAC situation, I'm not really sure thats a problem, except for the reset situation as you mentioned. But in principle if you want to re-use the state right after its keyed, you would marshal at that point, and keep on unmarshalling that for the copy of the state. For the reset situation, you're right it is confusing what to do there. I suppose it is an arbitrary decision, so the best option may be to use nil as the key. (Since there is no error return value)

I think for now it would be ok to make MarshalBinary return an error for keyed hashes. Once vgo happens we can think more about the API. Also, we'll know if it's a commonly requested feature and which version of it users expect.

I started an implementation for this, but I was wondering what I should do for test cases. The other hash functions (sha512, sha256, md5) have a TestGolden method, where they test the hash function with a known set of strings. There is no test golden method for blake2b. Should I make the same test golden method here, or is there another preferred way for testing this? The known test cases for blake2b are taken from here, but these were all produced with a key, which means that we would have to enable marshalling for keyed digests to use those test cases.
Also is it okay to serialize offset as uint32, and size as uint8? (offset seems to always be positive, and size never exceeds 64)

Hm - you could follow the same approach but instead of 2 instances of the hash function and a set of precomputed hashes you can use 3 hash instances and use the 3-th as reference.
Like:
h3, _ := New(nil)
h3.Write(testString)

// now do marshal/unmarshal test using h and h2
// compare h and h2 with h3

If we're using the current implementation as a reference, shouldn't only two hash instances be used? I.e. Write half the testString to h, then copy that to h2. Then write the remaining half of the state to both, and ensure that they are equal?


Upgarde quarkus to v0.26.1

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/camel-quarkus-pr/317/


[tlse] enable rabbitmq tls for internal TLS

If internal TLS is enabled, create cert for rabbitmq instance and configure the instance to use it. Non tls listeners will be disabled.
Jira: OSPRH-4413

Note, [1][2] for cinder not merged yet, so enabling tls for rabbitmq will make cinder to fail atm.
[1] https://github.com/openstack-k8s-operators/cinder-operator/pull/306
[2] https://github.com/openstack-k8s-operators/openstack-operator/pull/624


Feature/storage/blob tags

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run automation - sdk