Incorrect RabbitMQ transport_url values

Bug #1839307 reported by netproducts
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openstack-manuals
Invalid
Undecided
Unassigned

Bug Description

Everywhere in the documentation where a "transport_url" is specified (ex: Nova installation, Neutron installation doc, Keystone installation doc, Glance installation doc, and so on), the example syntax appears to be:

1) Incomplete;

It's unclear how to specify multiple rabbit hosts. Please indicate the somewhat strange scheme. I believe this is correct for Rocky, though it may change depending on release:

i) Start with 'rabbit://'
ii) append, comma separated, <username>:<password>@<host>:<port> quadruplets. Example:
nova:nova-pass@rabbit01:5672,nova:nova-pass@rabbit02:5672,nova:nova-pass@rabbit03:5672
iii) Append a single forward slash '/'.
iv) Append the name of the vhost, HTTP-URL-encoded. For the default vhost (if you did not configure any) the exact value will be '%2F'.

A full example string is this:
rabbit://nova:nova-pass@rabbit01:5672,nova:nova-pass@rabbit02:5672,nova:nova-pass@rabbit03:5672/%2F

2) Wrong.

RabbitMQ recently had a change where specifying no 'vhost' parameter no longer redirects to the default 'vhost' called '/' (a single forward slash, literal). So the transport_url parameter needs to include a vhost string. Again, how to specify this is really hard to find. A combination of digging and guesswork leads me to believe steps iii and iv are how to do it.

It would be nice if the docs just always included the 'vhost' param, instead of relying on the 'defaulting' behaviour that only works on older RabbitMQ versions. By explicitly specifying, openstack installations don't mysteriously break in all sorts of colourful python crashes when updating RabbitMQ.

3) No escaping information.

When combining many values (N quadruplets of user, passwd, host, port, plus vhost) into one string, sometimes some of these values may contain some of the symbols used to separate them. How do you escape in this custom string-format, and which symbols are disallowed? (This is a slightly lesser concern: I just make sure I use none of the control chars to not have to worry about it).

description: updated
description: updated
Revision history for this message
Siavash Sardari (siavash.sardari) wrote :

It is my first day on contributing to OpenStack, so I don't change the status and bug assignment. But I would like to express my opinion on this matter and in the way the bug was described.

1) I believe you want to use a Rabbitmq cluster. In that scenario there is two way to tackle the problem. First one is what you mentioned (and what is or should I say was covered in OpenStack high availability guide) and the second way is to use a loadbalancer like HAProxy and configure it to use Rabbitmq hosts as backends.

i) I didn't quite get what you mean by that. This is how you tell OpenStack services to use rabbitmq driver for RPC and/or notifications.
ii) This is one way to use Rabbitmq cluster. you are write about this. OpenStack manuals removed the high availability guide, there was way more practical information about using Rabbitmq cluster.
iii) and iv) it is up to you to use default vhost or a specific one. For example both bellow syntaxes are correct:

```transport_url = rabbit://RABBIT_USER:RABBIT_PASS@rabbit1:5672, RABBIT_USER:RABBIT_PASS@rabbit2:5672,RABBIT_USER:RABBIT_PASS@rabbit3:5672```
or
```transport_url = rabbit://RABBIT_USER:RABBIT_PASS@rabbit1:5672, RABBIT_USER:RABBIT_PASS@rabbit2:5672,RABBIT_USER:RABBIT_PASS@rabbit3:5672/VHOST```

2) Your comment on this is not wrong. actually, as I mentioned above you can go either way. In general I agree with you, the installation manuals can be more precise, but these matters are coverd in other parts of documentation like link bellow:

https://docs.openstack.org/oslo.messaging/latest/reference/transport.html

3) I think the above link will help you on this concern of yours.

Changed in openstack-manuals:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.