Custom cluster settings

Our QA and Production Environments only have access to internet via proxy server.

httpClient.request has support for proxy, yay :slight_smile:
http://repo.enonic.com/public/com/enonic/xp/docs/6.7.0/docs-6.7.0-libdoc.zip!/module-lib_xp_http-client.html#.request

However we only want to use the proxy in some instances, not for requests inside the firewall.

We could hardcode it, put it in site-config or a special config content-type.
But really this config does not belong to a single site, but the entire cluster.

Can we put some custom “environment” variables in some xp_home/config/*.cfg file, and have access to the value of it from inside our controllers?

Right now you could place the configuration into system.properties (but need restart for each change) and access them using System.getProperty('...'). In Javascript, that would be:

var System = Java.type('java.lang.System');
var myProp = System.getProperty('foo.bar.prop');

But, the ultimate solution here would be to allow cfg files for each app named the same as the app. For example, foo.bar.myapp could have a configuration file foo.bar.myapp.cfg inside $XP_HOME/config. When this file is changed, the app is restarted. And the app could then get the configuration from app.config variable.

The illustrated solution is not working right now, but I will describe it in a task (and discuss it internally). It should be pretty trivial to implement.

System.getProperty should suffice for now, but since there are multiple machines in the cluster, that would also mean I would have to update the system.properties file on all nodes, and restart Enonic on all nodes.

Most cfg files are identical on all nodes, while a few are different. Would it be a good idea to put the files that are identical on nfs, and make symlinks to them? That way one would only have to change one file?

I guess having config in blob store would be a more cluster friendly solution?

Yes, you could symlink to NFS but I am not sure if it will detect the changes since NFS attr-changes is a little bit slow.

In the long run we will have both configuration on disk (overrides) and configuration in the “database”. That would be the ultimate solution.