Split configuration file for easier management

[rolandkool]

Hi,

I'm planning on a rollout of glowroot across our test environment and enable it by default so developers could benefit from it when needed. However, we're dealing with a lot of applications and the rollout is going to be done using configuration management.
When I started work on this, I realised the configuration file in current form is not flexible enough. Most settings I'd like to centrally manage, but settings that are unique per application (the instrumentation for example) I'd like to be customizable per application. Of course this can be done with configuration management, but them the developers will need to be adding data in another place than glowroot UI.

So my suggestion would be to split the configuration file in logical parts (can even be two, instrumentation and the rest) so I can manage the files differently (or not manage them at all).

What do you think of this idea?

[trask]

Check out pure json defined plugin, this sounds like what you may be looking for, you can put the instrumentation in one or more json files under plugins directory, a little info on this at https://glowroot.org/plugins.html

[rolandkool]

The pure json plugin is useful, but I'm suspecting that developers will be using the GUI to create their instrumentation definitions. It would be helpful in that case if the instrumentation configuration GUI would write each entry into a separate JSON file in the plugins directory so the original config.json can be managed using configuration management and is not reset all the time, causing developers to loose custom instrumentations.
Does that sound like a good idea?

[trask]

Thanks, supporting this use case makes sense, I could see using this test environment deployment approach also.

I'm a little reluctant to drop the simplicity of "all config is stored in config.json". Also, wondering if it may end up being more than just instrumentation that is application-specific, e.g. also gauges and the servlet plugin's "session user attribute".

A thought is to support dropping a config-update.json (config-reset.json?) file into the glowroot folder (with same format as config.json), and the next time glowroot starts, it could read this and only update/reset the config properties present in this config-update.json. The "instrumentation" and "gauges" lists would probably each be all or nothing updates, but the rest of the settings could be individually included/excluded from the update/reset file. And then the update/reset file would be deleted after startup. I think this would address what you are looking for?

[rolandkool]

Currently, I'm managing the config.json so whenever it changes and the changes are not defined in the cfg mgmt system, the file is adjusted to reflect the default. A config-reset (or config-readonly?) could work as long as it is not deleted/touched by glowroot. Any changes in the config readonly file will be done by me (ops) to set some sane defaults for the port, db sizes, etc.

So on initial start, there is no config.json just a config-readonly/reset, a default config.json is created and it reads/merges any settings that I've provided beforehand in the config-readonly/reset.

Can this work for you too?

[trask]

I'm thinking of adding another user above Admin (called Owner) that would have all rights. Then Admin user would have all rights except updating access config (including port here), storage config and smtp config. In your scenario you would enable Owner account, and then either enable the Admin user, or give Anonymous users Admin access (in the dropdown).

Does this cover all the config settings you want to lock down (Access config shown below, Storage config same as current, SMTP config same as current but relocated from under Alerts)?

[trask]

For other reasons, I split out the UI preferences ("Default displayed transaction type" and "Default displayed percentiles") and Access configuration (port and authentication). You can see at https://demo.glowroot.org/config/access. I think this isolates things an Owner would want to lock down to Access/Storage/SMTP. I haven't implemented the Owner account yet. When you have a chance, let me know if this would cover your use case. Thanks.

[rolandkool]

Hi Trask,

Having a readonly portion of the configuration screen helps but solves only part of the problem.
When the configuration still exists as one file, I can't manage the file through configuration management as some components can still be updated by the users of this tool.
So having a defaults config file (managed by (in our case) operations through cfg mgmt) and a 'user' configfile (unmanaged / managed through the GUI) is still something I'd love to see.

[trask]

I split out access, storage and smtp sections into a new file, admin.json. This is available in the latest snapshot https://s3.amazonaws.com/glowroot/snapshots/glowroot-0.9.0-SNAPSHOT-dist.zip.