amqp: vhost in channel binding

[mr-nuno]

Describe the bug

When looking at the channelBindings for a amqp the vhost is on the channel level. But the vhost is really part of the amqp connection i.e. part of the authentication.

channels:
  user/signedup:
    bindings:
      amqp:
        is: routingKey
        queue:
          name: my-queue-name
          durable: true
          exclusive: true
          autoDelete: false
          vhost: /
        exchange:
          name: myExchange
          type: topic
          durable: true
          autoDelete: false
          vhost: /
        bindingVersion: 0.2.0

For example, user and password and vhost is used when authenticating against a amqp RabbitMQ broker. I don´t think the vhost is a part of the channel? When you look at the server part for a amqp broker. The vhost is already part of the url

servers:
  production:
    url: goose.rmq2.cloudamqp.com/hohmawct
    protocol: amqps

Expected behavior

Remove vhost from the channelBindings

channels:
  user/signedup:
    bindings:
      amqp:
        is: routingKey
        queue:
          name: my-queue-name
          durable: true
          exclusive: true
          autoDelete: false
        exchange:
          name: myExchange
          type: topic
          durable: true
          autoDelete: false
        bindingVersion: 0.2.0

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[smoya]

@mr-nuno thanks for submitting this issue. I took a quick look into it and indeed it makes sense to me that the virtual host shouldn't be in channel binding but instead, be grabbed from the server URL whenever is needed.
Starting from AsyncAPI spec v2.2.0, channels can be assigned to servers (see asyncapi/spec#531), so in case any tool needs to know about the virtual host from a channel point of view, that could be definitely done thanks to it.

I think I'm ok with this suggestion, however, I'm not an expert on AMQP. Let's see what others say so I'm pinging some people that at some point have been involved with this particular binding: @iancooper @olvlvl @ericsampson

[jonaslagoni]

Would you never want to have two channels use different vhost properties to the same server?

I.e. is this never a use-case 🤔?

servers:
  production:
    url: goose.rmq2.cloudamqp.com
    protocol: amqps
channels:
  user/signedup:
    bindings:
      amqp:
        is: routingKey
        queue:
          name: my-queue-name
          durable: true
          exclusive: true
          autoDelete: false
          vhost: /hohmawct
        bindingVersion: 0.2.0
  user/signedup2:
    bindings:
      amqp:
        is: routingKey
        exchange:
          name: myExchange
          type: topic
          durable: true
          autoDelete: false
          vhost: /hohmawct2
        bindingVersion: 0.2.0

[smoya]

Would you never want to have two channels use different vhost properties to the same server?

I.e. is this never a use-case 🤔?

servers:
  production:
    url: goose.rmq2.cloudamqp.com
    protocol: amqps
channels:
  user/signedup:
    bindings:
      amqp:
        is: routingKey
        queue:
          name: my-queue-name
          durable: true
          exclusive: true
          autoDelete: false
          vhost: /hohmawct
        bindingVersion: 0.2.0
  user/signedup2:
    bindings:
      amqp:
        is: routingKey
        exchange:
          name: myExchange
          type: topic
          durable: true
          autoDelete: false
          vhost: /hohmawct2
        bindingVersion: 0.2.0

The use case on having different vhost is valid. However, you could have one server per vhost if needed.

[jonaslagoni]

The use case on having different vhost is valid. However, you could have one server per vhost if needed.

Yes, that's what I am trying to get at. Is it just because you want to set the vhost at the server level as well, or that you want to move the channel vhost property? 🤔

[mr-nuno]

Good question 😃
What I'm probably getting at is that the vhost is already part of servers

servers:
  hohmawct:
    url: goose.rmq2.cloudamqp.com/hohmawct
    protocol: amqps
  hohmawct2:
    url: goose.rmq2.cloudamqp.com/hohmawct2
    protocol: amqps

It's not really part of the channelsBindings

[iancooper]

Overall this goes to a question I raised some time ago, how do we map AsyncAPI document objects to broker capabilities. For my part I would suggest:

• Routing & Store And Forward: Channels
• Middleware Host: Server

For RMQ I would map routing key and queue to channels (I can't see that being controversial) and vhost, exchange etc to server.

I think there is an argument for an explicit Broker object because Server is really Client-Server not Pub-Sub broker and it's a discussion I was hoping to have coming up

[mr-nuno]

For RMQ I would map routing key and queue to channels (I can't see that being controversial) and vhost, exchange etc to server.

For RMQ, I think that channels are routing keys and a channel(routing key) can then declare a exchange or a queue in the binding. I'm not quite with you on why the exchange should be on the server level?

But for this issue the question is if the vhost belongs to the channelBindings 😃

[olvlvl]

Hi everyone,

Although vhost is part of the connection string, the server definition is not part of the binding, thus I would leave the vhost where it is. Moving vhost to the server connection would prevent having different vhost per queue/exchange, which was very common in my previous company (vhost per domain).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️