Rename artemis-broker to artemis-broker-primary
This commit renames and refactors the Helm chart for the
artemis-broker. The original files in the artemis-broker
directory are renamed and moved to artemis-broker-primary.
The purpose of this change is to enable a clear
distinction between the primary broker configuration and any
backup or alternative configurations.
Additionally, the configuration has been updated to support
enhancements in TLS setup, metrics services, and users,
allowing for a more robust and flexible deployment.
This change introduces new templates and scripts needed
for managing various aspects of the broker's functions,
including improved user authentication and logging. No
breaking changes were introduced, but users must update
their references to the chart paths as they now point to
the new directory structure.
```
Rename `values_helmChart__passive.yaml` to
`values_helmChart__backup.yaml` and `values_helmChart.yaml` to
`values_helmChart__primary.yaml`.
These changes improve file clarity by explicitly indicating
the purpose of each values file. The primary configuration
is now more identifiable with its new name, while the backup
file is clearly designated, reducing confusion for future
updates and maintenance. There are no breaking changes
associated with these renames.
Bump artemis-broker version to 7.12.3-test2
Updated the version of the artemis-broker Helm chart from
7.12.3-test1 to 7.12.3-test2 in the Chart.yaml file. This
increment is part of our development workflow to reflect
ongoing changes and enhancements in the broker setup.
No breaking changes were introduced in this version update.
```
This commit adds support for specifying pod affinity settings
in the Kubernetes pod template for the Artemis broker Helm chart.
The changes include a new conditional block in the `_pod.tpl`
template file that allows users to define affinity rules in
the `values.yaml` file under the `affinity` key.
The addition was necessary to provide users with more flexibility
in scheduling their pods based on node characteristics, which is
essential for optimizing resource allocation and achieving desired
deployment strategies.
No breaking changes were introduced, and the default `affinity`
configuration remains empty, ensuring backward compatibility.
