Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RabbitMQ Container doesn't preload exchanges configuration if provided #186

Closed
nebtrx opened this issue Aug 20, 2021 · 3 comments
Closed

Comments

@nebtrx
Copy link

nebtrx commented Aug 20, 2021

Hi fellows

First, I want to congratulate you guys for the hard work on this.

Having said that, I was using testcontainers-scala-rabbitmq for spinning up a container for test purposes when I noticed the exchange configuration I was trying to preload in the containers was not working.

The following is the container bootstrap code I used to provide a test-exchange exchange

val container: RabbitMQContainer = RabbitMQContainer(
    dockerImageName = DockerImageName.parse("rabbitmq:3-management"),
    adminPassword = RabbitMQContainer.defaultAdminPassword,
    queues = Seq.empty,
    exchanges = Seq(Exchange(
      name = "test-exchange",
      exchangeType = "direct",
      autoDelete = false,
      internal = false,
      durable = true,
      arguments = Map.empty,
      vhost = Some("test-vhost"))
    bindings = Seq.empty,
    users = Seq(User(
      name = "test-user",
      password = "test-password",
      tags = Set("administrator"))),
    vhosts = Seq(VHost(name = "test-vhost")),
    vhostsLimits = Seq.empty,
    operatorPolicies = Seq.empty,
    policies = Seq.empty,
    parameters = Seq.empty,
    permissions = Seq(Permission(
      vhost = "test-vhost",
      user = "test-user",
      configure = ".*",
      write = ".*",
      read = ".*"))
  )

I used the Rabbit's web admin interface to recover the instance configuration json and, as you can see, below. There was no exchange configuration being delivered to the container.

{
  "rabbit_version": "3.7.18",
  "users": [
    {
      "name": "guest",
      "password_hash": "<hash>",
      "hashing_algorithm": "rabbit_password_hashing_sha256",
      "tags": "administrator"
    },
    {
      "name": "test-user",
      "password_hash": "<hash>",
      "hashing_algorithm": "rabbit_password_hashing_sha256",
      "tags": "administrator"
    }
  ],
  "vhosts": [
    {
      "name": "test-vhost"
    },
    {
      "name": "/"
    }
  ],
  "permissions": [
    {
      "user": "guest",
      "vhost": "/",
      "configure": ".*",
      "write": ".*",
      "read": ".*"
    },
    {
      "user": "guest",
      "vhost": "test-vhost",
      "configure": ".*",
      "write": ".*",
      "read": ".*"
    },
    {
      "user": "test-user",
      "vhost": "test-vhost",
      "configure": ".*",
      "write": ".*",
      "read": ".*"
    }
  ],
  "topic_permissions": [],
  "parameters": [],
  "global_parameters": [
    {
      "name": "cluster_name",
      "value": "rabbit@bc156650f5aa"
    }
  ],
  "policies": [],
  "queues": [],
  "exchanges": [],
  "bindings": []
}

I got curious and started looking under the hood in then I realised that exchanges initialization happens before vhost initialization. Since my exchange was tied to a vhost initialized later one it seemed possible this was the root cause of the issue.

I played with a local implementation pushing vhost initialization upwards in the JavaRabbitMQContainer bootstrapping code and it worked like a charm.

If you don't mind I'll push a PR fixing this issue later Today

@dimafeng
Copy link
Collaborator

Thanks for reporting! Please push a PR when you have a chance

@nebtrx
Copy link
Author

nebtrx commented Aug 23, 2021

Done @dimafeng ! Workflow is awaiting approval

@nebtrx
Copy link
Author

nebtrx commented Aug 31, 2021

Closing this one since #187 addressed it

@nebtrx nebtrx closed this as completed Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants