Enhancement: Allow for the configuration of Hazelcast cluster to be done via Environment Variables

[CarlosMOGoncalves]

Brief Summary

Currently, in Payara Micro, it is possible to configure the Hazelcast cluster via some asadmin commands triggered in the boot command files or via an Hazelcast configuration file.

The commands are rather limited when one wants to configure Hazelcast for a complex deployment kind, for example to use the cloud-specific plugins.

The config file does work as expected, but it is not a very practical solution for containerised environments as either the file has to be bundled into the image or it needs to be fed from the outside to the container (for example, via a volume) so that it can be loaded from Payara.

My suggested enhancement is to introduce the option for the configuration of the cluster to be made via Environment Variables, so that custom configuration can be applied to Payara Micro based applications running in containers in an easier way.

Expected Outcome

When using Payara Micro - and Server too - it should be able to read Environment Variables and use them to config the Hazelcast instance.

Current Outcome

Only through asadmin commands and hazelcast config file it is possible to configure the Hazelcast cluster

Alternatives

The alternatives are already implemented.

Context

Currently Hazelcast can already load configurations via Environment Variables, which was the reason that made me ask this here. They use a simple notation for such, as can be seen here: Config Hazelcast with Env Variables.

However, I do see in your code that you are loading configurations upfront to build a Config object and passing it to the Hazelcast library in order to build an instance and this, sadly, bypasses any attempt that Hazelcast itself would do to load those environment variables.

[lprimak]

Hi,

Is specifying your own hazelcast config file in Payara solve your problem?

[CarlosMOGoncalves]

Thanks for the quick reply Lenny.

Specifying my own config file is a possible solution and in fact it is the only one I know that I can use for complex configurations of Hazelcast.

However, as I mentioned in the enhancement request, I don't think it is the most practical one in a containerised environment as it needs to be bundled into the image every time a change is performed.

Using Env variables would allow for simple configuration on container startup.

Which is why I think the possibility of using the same set of environment variables that Hazelcast supports would be of great value.

[lprimak]

Ok, sorry I didn't read your post carefully :)

Payara has to plug it's own integration points into Hazelcast configuration. Because of this, it's not possible to completely remove configuration portion of initialization code.

Because of this, unfortunately I don't think your request is possible to implement.

[CarlosMOGoncalves]

It might be.

Although I am finding the configuration code a bit difficult to follow, I think it might be possible if the Env variables are loaded as part of the buildConfiguration() function.

The config file seems to take precedence over the standard Payara configurations so it would likely be possible to load Env variables before (or after) the file. Maybe even with some override mechanism (so that either the config file or the variables have some sort of precedence over each other in a similar way that they have precedence rules on Hazelcast itself).

Also another option (maybe, just maybe, it is very very late and I am reading it diagonally) would be to leverage Hazelcast's own configuration mechanisms to keep the current behaviour (Payara defaults + config file) and add the Env variables one.

In their documentation they state that "If you use [configuration builders] or the new Config() constructor with the Java member API, you cannot override existing configuration with system properties and environment variables. To override existing configuration, you must use [configuration loaders]." So there might be something worth exploring.

Alas, I digress a bit.
I would very much appreciate if the Payara team could discuss this matter internally and if you find value in this Enhancement, for both you and the community, it would be worth implementing.

My personal view on the matter is that Hazelcast is a very important component that greatly enhances Payara's capabilities and I think this would be a very useful enhancement, but of course, that is just my humble opinion :).

[lprimak]

You may be right, I would say it's worth at least exploring, but I would guess it needs to be prioritized appropriately as you say.

[CarlosMOGoncalves]

Thanks a lot for your positive consideration into this matter.
I know it must be a lot of work, but I would really appreciate if the team would look into this and, if possible, to keep the community updated about the matter.
Please reach out if I didn't write the request clearly enough or for further discussion.
Cheers!

[skipper4]

Hello @CarlosMOGoncalves,

The proposed enhancement has been submitted for an open vote.