14.04 - Openstack Juno Rabbitmq Charm: Config File Missing - Ask Ubuntu
to customize your list.
Ask Ubuntu is a question and answer site for Ubuntu users and developers. J it only takes a minute:
Here's how it works:
Anybody can ask a question
Anybody can answer
The best answers are voted up and rise to the top
Trying to deploy a multi-node openstack Juno, on 14.04. Here is my charm config file:
nova-cloud-controller:
openstack-origin: cloud:trusty-juno
network-manager: "Neutron"
openstack-dashboard:
openstack-origin: cloud:trusty-juno
openstack-origin: cloud:trusty-juno
openstack-origin: cloud:trusty-juno
openstack-origin: cloud:trusty-juno
ext1-quantum-gateway:
openstack-origin: cloud:trusty-juno
ext2-quantum-gateway:
openstack-origin: cloud:trusty-juno
nova-compute:
openstack-origin: cloud:trusty-juno
On Juju gui, all nodes and rela however, I cannot access
Project->Access&Security page, under horizon. Looking at rabbitmq log files, it seems that all access, from various services, are denied:
# tail -f /var/log/rabbitmq/rabbit@rabbitmq1.log | grep access_refused -B2 -A3
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17775.0& (10.0.0.77:34733 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17778.0& (10.0.0.77:34734 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17781.0& (10.0.0.77:34735 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17784.0& (10.0.0.77:34736 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17787.0& (10.0.0.75:54438 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17790.0& (10.0.0.62:39103 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17793.0& (10.0.0.62:39104 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17796.0& (10.0.0.62:39105 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17799.0& (10.0.0.75:54439 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17803.0& (10.0.0.62:39106 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17806.0& (10.0.0.62:39107 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17809.0& (10.0.0.62:39108 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17812.0& (10.0.0.62:39109 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'nova' - invalid credentials",
'connection.start_ok'}}
closing AMQP connection &0.17815.0& (10.0.0.77:34737 -& 10.0.0.60:5672):
{handshake_error,starting,0,
{amqp_error,access_refused,
"AMQPLAIN login refused: user 'neutron' - invalid credentials",
'connection.start_ok'}}
Looking under /etc/rabbitmq, I don't see any files! Removing and adding relations, per , did not resolve the problem. Here are some typical diagnostics:
rabbitmqctl list_users
Listing users ...
[administrator]
nagios-rabbitmq-server-0
neutron []
# rabbitmqctl list_permissions -p openstack
Listing permissions in vhost "openstack" ...
neutron .*
rabbitmqctl list_vhosts
Listing vhosts ...
nagios-rabbitmq-server-0
Any thoughts?
Edit 1: Seems that cloud:trusty-juno charms are not compatible with rabbitmq charm. For cinder and nova-cloud-controller had to set notification_driver =
rabbit. Furthermore,
had to manually set password, in rabbitmq server, for nova, neutron, and cinder users. In all cases, had to restart relevant services, manually. (Note that in case of cinder and cloud-controller, juju overwrites notification_driver.) Unfortunately, still can't access Access&security page. Keystone is reporting the following:
(mon.wsgi):
23:51:42,238 WARNING Authorization failed. The request you have made requires authentication. from 10.0.0.62
(mon.wsgi):
23:51:42,251 WARNING Expecting to find username or userId in passwordCredentials - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error.
10.0.0.62 being nova-cloud-controller.
Edit 2: (vis-a-vis 1st response.)
# sudo rabbitmqctl cluster_status
Cluster status of node rabbit@rabbitmq1 ...
[{nodes,[{disc,[rabbit@rabbitmq1]}]},
{running_nodes,[rabbit@rabbitmq1]},
{partitions,[]}]
Looking forward to the next release.
The charm updates to support the Juno OpenStack release are fully compatible with the RabbitMQ charm - we test this on every commit we make to any of the OpenStack charms as part of the day-to-day charm development cycle.
The RabbitMQ (rabbitmq-server) charm should be automatically creating users under the openstack vhost for all related services, and providing a password back via relation data to cinder, nova, neutron etc...
This is all done directly in RabbitMQ's underlying state database - so don't expect anything to appear in /etc/rabbitmq!
For some reason, it looks like this password does not correspond with the password in RabbitMQ - you're running in a clustered configuration so I wonder whether there is some issue with the clustering - try running:
sudo rabbitmqctl cluster_status
on one of the RabbitMQ nodes to see if
I suspect there may have been some issue with the RabbitMQ clustering set-up, and you might be running in some sort of split brain configuration, so the passwords remote services have only match in a subset of the RabbitMQ units.
I also checked on the notification driver configuration for the cinder and nova- although they are using the older deprecated name for the rpc driver, this gets remapped to the correct oslo.messaging (the shared OpenStack messaging library) driver. We'll update this during our
to use the oslo.messaging one directly.
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
Ubuntu and Canonical are registered trademarks of Canonical Ltd.
Ask Ubuntu works best with JavaScript enabledActive Posts
Recently Visited
Search Results
" data-extrabar="/forums/ws/extrabar.aspx?mid=488342&t=true&o=m&w=true&p=true .sidebarUrlWrap">Page Extras
Forum Themes
Why CDC Serial Device installation fails on Windows Vista and 7 ?
Why CDC Serial Device installation fails on Windows Vista and 7 ?
Super Member
Windows Vista (x86 32bit) - Source of usbser.sys: C:\Windows\System 32\DriverStore\FileRepository\mdmcpq.inf_e99692b4 (archive file) - Destination to copy: C:\Windows\System 32\drivers
Windows Vista (x64 64bit) - Source of usbser.sys: C:\Windows\System 32\DriverStore\FileRepository\mdmcpq.inf_ec18f765 (archive file) - Destination to copy: C:\Windows\System 32\drivers
Windows 7 (x86 32bit) - Source of usbser.sys: C:\Windows\System 32\DriverStore\FileRepository\mdmcpq.inf_x86_neutral_1b9e317b (archive file) - Destination to copy: C:\Windows\System 32\drivers
Windows 7 (x64 64bit) - Source of usbser.sys: C:\Windows\System 32\DriverStore\FileRepository\mdmcpq.inf_amd64_neutral_9bbf7ae (archive file) - Destination to copy: C:\Windows\System 32\drivers
Bug fix of microchip INF files
mchpcdc.inf (and its derivatives)
[DestinationDirs] FakeModemCopyFileSection=12 &------ add this line DefaultDestDir=12
[DriverInstall.nt] include=mdmcpq.inf ;; CopyFiles = DriverCopyFiles. &------ wrong one: reference to this INF file CopyFiles = FakeModemCopyFileS &------ right one: reference to a section in mdmcpq.inf AddReg=DriverInstall.nt.AddReg
;; [DriverCopyFiles.nt] &------ delete these lines ;; usbser.sys,,,0x20 &------
Background of the bug
a) Source location of usbser.sys There is no difference on the CDC (usbser.sys) INF file among Win XP, Vista and 7 The major difference lies in the pre-installation of usbser.sys to the driver folder on each PC.
Most of Win XP pre-install still have usbser.sys in the driver folder, For Vista and 7, usbser.sys is not installed there, but it is held in the installation archive. When INF [SourceDisk] section points to this archive correctly, usbser.sys is copied from the archive.
MS has warned to us not to refer usbser.sys source location directly on our custom INF file. Instead, they suggest to "include" mdmcpq.inf AND refer to "FakeModemCopyFileSection" (awful naming sense) section, because mdmcpq.inf of each pre-installation knows the right place on which the original usbser.sys exists (*2).
Just writing "include = mdmcpq.inf" does nothing. Refer to the section, "FakeModemCopyFileSection", correctly.
Current version of Microchip INF file works just when usbser.sys has been already copied to the driver folder manually, or by another right INF file.
b) Driver signing on 64bit Windows Above bug fix to INF file breaks driver signing of the installation package. Broken sign prevents us from installation and use on 64bit Windows, unless we apply test-mode power up. To complete the fix, we have to wait for Microchip until they get driver signing again.
(*1) there is no space on the folder name, "System 32". but without the space, this forum engine rejects my post
(*2) "How to use or to reference the Usbser.sys driver from universal serial bus (USB) modem .inf files"
Super Member