Deprecation of activemqartemisaddresses and activemqartemissecurities

[subhidh-agarwal]

I noticed that the CRDs ActiveMQArtemisAddresses and ActiveMQArtemisSecurities have been deprecated in the new version of the ActiveMQ Artemis Operator. I'm assuming this means they will likely be removed in a future release.

These CRDs were quite useful for defining queues and security settings separately using dedicated YAML files. This made configurations more modular, easier to manage, and allowed for fine-grained control over different aspects of the broker.

Now, with the new approach, all configurations—including queues, addresses, and security settings—must be defined inside ActiveMQArtemis under broker.properties. While this keeps everything in one place, it does raise some concerns about manageability and separation of concerns.

A few advantages of using separate YAML files (like before) were:

Better Modularity – Security rules and address configurations could be handled separately, reducing complexity.
Easier Updates – Updating security policies or queue configurations could be done independently without modifying the main broker definition.
Cleaner Git History – Changes to specific settings had more atomic commits, making audits and rollbacks simpler.
Reduced Risk – Mistakes in security settings wouldn't directly impact broker-level configurations.

I’d love to understand the reasoning behind this deprecation. Was there a specific challenge with managing these CRDs that led to this decision? Are there any recommended best practices for handling configurations efficiently in the new setup?
Looking forward to hearing your thoughts!

Also, I noticed that the CRD file in Git doesn’t seem to be updated. Could someone check if that needs to be updated in the repository?

[gtully]

To address the modularity concern first, you can split your config across secrets or across files in a secret. There is support for a "-bp" suffix secret extra mount that can contain broker configuration.

But in general, having your address.properties and security.properties files in git, and building a secret from git sources is a sensible approach. Property files are read and applied in alphabetical order but can be split by function or policy.

As to the why for broker properties. They are applied from disk (through a volume mount projection) to the broker and support reload. They are extensible, any attribute of the Configuration Bean can be modified. They are independent of the xml schema which gives them broker version independence.

The address and security crs have been largely about converting xml config into yaml. While useful, they are brittle and need updates for every new addition to the broker.
The security cr requires a restart for changes to take effect, there is no use of config reload.
The address cr ,uses JMX which is controlled by security, so there is a chicken and egg problem with permissions. In addition there needs to be an address cr per queue.

There is a problem though, broker properties are not a better way to configure a broker, they are just an alternative means of modifying the existing internal configuration bean. They expose the full configuration API, but are not generally user friendly.

We are working to address this, through two new CRs, one that will create a broker service and a second that will onboard an application to a broker service. The operators behind these CRs will know how to write broker properties and will work with an existing ActiveMQArtemisCR in restricted mode, simpler and more deterministic than what we currently have.
That is the long term plan and goal, brokerProperties are a necessary stepping stone on that journey and we are only at the beginning.