jfrog / JFrog-Cloud-Installers

Template to deploy Artifactory Enterprise cluster.
Apache License 2.0
78 stars 140 forks source link

[ansible/xray] archive.yml does not cluster RabbitMQ #412

Open jonathanwehner opened 1 month ago

jonathanwehner commented 1 month ago

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug?

Which installer: Ansible

Which product and version (eg: ansible & collection version - 7.24.2): Ansible collection/Xray 3.102.3

Which operating system and version(eg: ubuntu & version - 20.4): Debian Bullseye

Which product license (Enterprise/Pro): Enterprise+

What happened: archive.yml does not provide the correct answers to the installer script which add the rabbitmq active node name to secondary node's system.yaml file.

    - {
        "expecting": "are you adding an additional node",
        "sending": "{% if xray_ha_node_type is defined and xray_ha_node_type == 'master' %}n{% else %}y{% endif %}"
      }

The script will answer y to add an additional node and reach the rabbitmq prompts without adding an undocumented value for xray_ha_node_type to the secondary nodes.

    - {
        "expecting": "rabbitmq active node name:",
        "sending": "{{ ansible_machine_id }}"
      }
    - {
        "expecting": "rabbitmq active node ip:",
        "sending": "{{ ansible_host }}"
      }

After adding such a value, these two values refer to the node installing Xray rather than the first node, which we should be clustering RabbitMQ on. The first is the most relevant value, as we would only need the second in Docker Compose installations.

The following does result in a successful clustering:

    - {
        "expecting": "rabbitmq active node name:",
        "sending": "{{ hostvars[groups['xray_servers'][0]]['ansible_hostname'] }}"
      }

What you expected to happen: The playbook installs an Xray cluster with a clustered RabbitMQ, instead of requiring manual clustering.

How to reproduce it (as minimally and precisely as possible): Install multiple Xray nodes with the playbook

Anything else we need to know: No