Override New Relic agent configuration from User-Provided Service payload with user defined JAVA_OPTS

[bryancuster]

As a follow up to #173, it would be valuable for the new_relic_agent framework to look at the current JAVA_OPTS, and only add to the configuration map if the key is not already defiened. This would allow users to override values if they desire.

Something along the lines of:

def apply_user_configuration(credentials, configuration, java_opts)
    credentials.each do |key, value|
        configuration[key] = value unless java_opts.contains_system_property("newrelic.config.#{key}")
    end
end

[cgfrost]

Hi, thanks for raising this issue. Could you expand in the use case a little, why do you want existing JAVA_OPTS to win over user provided service credentials? If we do this then obviously the code is very simple but we would also need to print out warning messages saying which service credentials were ignored otherwise it could get confusing for users.

Tracker issue here: https://www.pivotaltracker.com/story/show/102143072

[bryancuster]

Since #173 was implemented, allowing for any system property to be set (ie newrelic.config.*), it would be helpful that anything included in the 'newrelic' service is considered default and system properties provided in a manifest file, for instance, takes precedence.

We use Cloud Foundry is very centrally managed manner and provision a 'newrelic' service in every space platform wide. When it is created, it is also populated with contextual data via labels (Space name, Organization name, etc). We are encouraging developers to use the service because it is so simple and streamlined to enable New Relic monitoring.

Example Service:

              "credentials": {
                "proxy_port": "80",
                "proxy_host": "proxy.mycorp.com",
                "log_file_name": "STDOUT",
                "license_key": "123xyz",
                "labels": "Environment:Test\\;Business_Unit:My_Business_Unit\\;Organization:My_Organization\\;Location:AWS_East"
              }

However, it is not currently possible for an application team to use their own labels while still benefiting from the licence_key and proxy configuration. Right now our only use cases is labels, but I could see it also being useful for log_file_name, log_level, and any new properties that New Relic might add.

[nebhale]

Resolved in 5c66fe7.