Bug 1789147
| Summary: | When overriding rabbitmq_environment and rabbitmq_config_variables while not adding newer settings, overcloud deployment could fail | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | David Hill <dhill> |
| Component: | openstack-tripleo-heat-templates | Assignee: | RHOS Maint <rhos-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Sasha Smolyak <ssmolyak> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 13.0 (Queens) | CC: | lmiccini, mburns, ramishra |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-01-09 15:00:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
IMHO this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1780399. The issue is a change in puppet-rabbitmq, coupled with the override done in the templates that removed the necessary loopback users config option. Reworking the way rabbitmq_config_variables works would need coordinated changes in tht/puppet and is unlikley to happen in OSP13 if at all (not exposing partition_handling and queue_master_locator was a deliberate choice). I'll discuss with the relevant team and see if we can revisit this decision for future releases. *** This bug has been marked as a duplicate of bug 1780399 *** |
Description of problem: When overriding rabbitmq_environment and rabbitmq_config_variables while not adding newer settings, overcloud deployment could fail due to missing newer settings. In the following example, the default values for those are this: rabbitmq_environment: NODE_PORT: '' NODE_IP_ADDRESS: '' RABBITMQ_NODENAME: "rabbit@%{::hostname}" RABBITMQ_SERVER_ERL_ARGS: '"+K true +P 1048576 -kernel inet_default_connect_options [{nodelay,true}]"' RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS: {get_param: RabbitAdditionalErlArgs} 'export ERL_EPMD_ADDRESS': "%{hiera('rabbitmq::interface')}" rabbitmq_kernel_variables: inet_dist_listen_min: '25672' inet_dist_listen_max: '25672' net_ticktime: {get_param: RabbitNetTickTime} rabbitmq_config_variables: cluster_partition_handling: 'ignore' queue_master_locator: '<<"min-masters">>' loopback_users: '[]' but customer overrode it with: rabbitmq_environment: RABBITMQ_NODENAME: "rabbit@%{::hostname}" RABBITMQ_SERVER_ERL_ARGS: '"+K true +P 1048576 -kernel inet_default_connect_options [{nodelay,true},{raw,6,18,<<30000:64/native>>}] -kernel inet_default_listen_options [{raw,6,18,<<30000:64/native>>}]"' rabbitmq_config_variables: cluster_partition_handling: 'ignore' . This prevented all services from connecting to the AMQP server due to the missing looback_users: '[]' directive. Shouldn't we do something like a left join / right join a la mysql here in order to avoid this in the future ? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. override rabbitmq_config_variables with missing loopback_users: '[]' directive 2. deploy your overcloud 3. Actual results: Fails Expected results: Succeed Additional info: This requirement was introuduced in 13z9 and is still present in 13z10.