Bug 1373233 - puppet-neutron doesn't set rabbit_port
Summary: puppet-neutron doesn't set rabbit_port
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-tripleo
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ga
: 10.0 (Newton)
Assignee: Brent Eagles
QA Contact: Amit Ugol
Depends On:
TreeView+ depends on / blocked
Reported: 2016-09-05 14:47 UTC by Cyril Lopez
Modified: 2016-12-14 15:56 UTC (History)
9 users (show)

Fixed In Version: puppet-tripleo-5.3.0-7.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-12-14 15:56:57 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2948 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 enhancement update 2016-12-14 19:55:27 UTC
OpenStack gerrit 386761 None None None 2016-10-14 20:07:58 UTC

Description Cyril Lopez 2016-09-05 14:47:22 UTC
Description of problem:
puppet-neutron doesn't set rabbit_port in neutron.conf.

It's fix on master branch of puppet-neutron.

It doesn't work for 8.0 and 9.0.

Version-Release number of selected component (if applicable):

How reproducible:
Deploy with this env :
    rabbitmq::ssl: True
    rabbitmq::ssl_cert: /etc/pki/tls/private/overcloud_endpoint.pem
    rabbitmq::ssl_key: /etc/pki/tls/private/overcloud_endpoint.pem
    rabbitmq::ssl_port: 5671
    neutron::rabbit_port: 5671
    neutron::rabbit_use_ssl: True

Steps to Reproduce:
1. deploy with env in osp-d 8.0
2. it will fail cause neutron rabbit_port is not set

Actual results:

# The RabbitMQ broker port where a single node is used. (integer value)
# Deprecated group/name - [DEFAULT]/rabbit_port
# rabbit_port = 5672

Expected results:

# The RabbitMQ broker port where a single node is used. (integer value)
# Deprecated group/name - [DEFAULT]/rabbit_port
# rabbit_port = 5672
rabbit_port = 5671

Additional info:
It's solved upstream but it's refactirused with puppet-oslo

Comment 2 Andreas Karis 2016-09-06 12:46:00 UTC
I'm adding this comment from the ticket directly here. It contains some analysis of the issue and in the very end I suggest a workaround which was confirmed by Cyril



The bug that we are talking about seems to be (partly) by design and comes back to what I mentioned in my previous email. `rabbit_port` should only be set in the case of one controller only (even though you proved that it works for multiple controllers as well):
  if $rpc_backend == 'rabbit' or $rpc_backend == 'neutron.openstack.common.rpc.impl_kombu' {
    if ! $rabbit_password {
      fail('When rpc_backend is rabbitmq, you must set rabbit password')
    if $rabbit_hosts {
      neutron_config { 'oslo_messaging_rabbit/rabbit_hosts':     value  => join($rabbit_hosts, ',') }
      neutron_config { 'oslo_messaging_rabbit/rabbit_ha_queues': value  => true }
    } else  {
      neutron_config { 'oslo_messaging_rabbit/rabbit_host':      value => $rabbit_host }
      neutron_config { 'oslo_messaging_rabbit/rabbit_port':      value => $rabbit_port }
      neutron_config { 'oslo_messaging_rabbit/rabbit_hosts':     value => "${rabbit_host}:${rabbit_port}" }
      neutron_config { 'oslo_messaging_rabbit/rabbit_ha_queues': value => false }

For as long as `rabbit_hosts` is provided, which is the case in any deployment at least of OSP 8 and later, regardless of the number of controller nodes. You can validate this by having a look at 
[root@overcloud-controller-0 ~]# grep rabbit_host /etc/neutron/neutron.conf 
# rabbit_host=localhost
# rabbit_hosts=$rabbit_host:$rabbit_port
# Deprecated group/name - [DEFAULT]/rabbit_host
# rabbit_host = localhost
# Deprecated group/name - [DEFAULT]/rabbit_hosts
# rabbit_hosts = $rabbit_host:$rabbit_port
rabbit_hosts =
[root@overcloud-controller-0 ~]# grep rabbit_host /etc/puppet/hieradata/* -R
/etc/puppet/hieradata/all_nodes.yaml:ceilometer::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:cinder::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:glance::notify::rabbitmq::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:heat::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:keystone::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:neutron::rabbit_hosts: ['']
/etc/puppet/hieradata/all_nodes.yaml:nova::rabbit_hosts: ['']
[root@overcloud-controller-0 ~]# 

I think that RabbitClientPort could be an option, although I will need to validate this.
  RabbitClientPort: 5671

    rabbitmq::ssl: True
    rabbitmq::ssl_cert: /etc/pki/tls/private/overcloud_endpoint.pem
    rabbitmq::ssl_key: /etc/pki/tls/private/overcloud_endpoint.pem
    rabbitmq::ssl_port: 5671
    neutron::rabbit_port: 5671
    neutron::rabbit_use_ssl: True

Also, I _do_ have a doubt abouter RabbitClientPort, because of:
cat /usr/share/openstack-tripleo-heat-templates/overcloud-without-mergepy.yaml
    default: false
    description: >
        Rabbit client subscriber parameter to specify
        an SSL connection to the RabbitMQ host.
    type: string
    default: 5672
    description: Set rabbit subscriber port, change this if using SSL
    type: number

Which sets neutron::rabbit_port, which of course doesn't work (see above)
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:        rabbit_client_port: {get_param: RabbitClientPort}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                cinder::rabbit_port: {get_input: rabbit_client_port}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                heat::rabbit_port: {get_input: rabbit_client_port}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                keystone::rabbit_port: {get_input: rabbit_client_port}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                neutron::rabbit_port: {get_input: rabbit_client_port}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                ceilometer::rabbit_port: {get_input: rabbit_client_port}
/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml:                nova::rabbit_port: {get_input: rabbit_client_port}

Which means that we'd have to look for a way to change the port for `rabbit_nodes`
/usr/share/openstack-tripleo-heat-templates/puppet/manifests/overcloud_controller.pp:  $rabbit_nodes = hiera('rabbit_node_ips')

Which is set by the following
/usr/share/openstack-tripleo-heat-templates/overcloud-without-mergepy.yaml:      rabbit_node_ips: {get_attr: [ControllerIpListMap, net_ip_map, {get_param: [ServiceNetMap, RabbitMqNetwork]}]}

Unfortunately,  cannot find anything that looks as if it were made for this port change ...

If `RabbitClientPort` does not help (as I would expect right now), a workaround for this issue could be the following:
        value: '5671'

      - ::neutron::config

I am going to try both variations in my lab, but you may actually me faster (I just came back from vacation and have to setup my labs again).



Comment 3 Brent Eagles 2016-10-14 18:14:24 UTC
As per the analysis in #c2, puppet-oslo is sidestepping this parameter. The suggested workaround might work but it may be preferable to amend the rabbit_hosts value to be host_ip:port.

Comment 4 Brent Eagles 2016-10-14 18:15:02 UTC
This also affects all services, not just neutron.

Comment 6 Amit Ugol 2016-11-29 15:24:57 UTC
adding only 'neutron::rabbit_port: 5671' to an environment file and deploying did not set the value as expected. Do I need to do a full SSL deployment to see this change?

Comment 8 Brent Eagles 2016-12-02 13:37:35 UTC
You should set the heat template parameter, not the hieradata. There is logic in the puppet-tripleo module that consumes the heat data and ensures the proper placement of rabbit host and port data.

Comment 9 Amit Ugol 2016-12-07 11:56:04 UTC
Target release is 10 in this case, and templates are completely different in 10. In any event, OOB the rabbitmq is set so the initial issue of not being able to deploy is not relevant and is irrelevant in 7,8 and 9 since those are already out in the wild.

Comment 11 errata-xmlrpc 2016-12-14 15:56:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.