While I don't know what the ultimate solution is, I do feel like the current situation for configuring plugins for the agent2 is overly cumbersome and an ever moving target.
As time has marched forward, more and more plugins are added to the agent2 release.
This is fantastic, I'm never not for this.
However, all of these keys for these plugins end up stuffed at the bottom of the agent2.conf.
If this is a fresh install, thats not really a problem.
But if I have an existing install, and I want to upgrade from a previous release, I now need to either punt on a new config from the repo which will break my install (easy and what I end up doing), or I need to meticulously merge the config on every host (not easy).
And while config management with something like salt allows me to have and push configs to all machines, I now need to go merge changes to then push out, which isn't the end of the world, but seems like it can lead to fat finger issues, etc.
What I feel like would be both easier to use and manage, is if these plugin config keys were stored in agent2.d/.
This allows more granular conf file changes when new plugins are added (just add a new conf file in agent2.d when a new plugin is added), as well as grouping things logically.
While some plugins like plugins.systemrun have one key, some plugins like ceph have 6, mysql 5, oracle 8, etc.
On top of that, on a fresh 5.0.9 agent2 install, I have plugins.docker keys both above and below the 6 ceph keys, which if I'm not looking hard, I could miss one or the other key when trying to configure docker for instance.
And to compound all of this even further, I think there is a certain level of duplicity and confusion with some of these keys too.
I know that the mysql and postgres and ceph all have locations to configure the credentials in either the agent2.conf, or using template macros, though some features only exist in the agent2.conf, and you end up with bifurcated configs.
For instance, I have my ceph-agent2 instance configured with macros, but I also need to Plugins.Ceph.InsecureSkipVerify=true, which can only be done from the config file.
Point being, I think it is extremely messy and convoluted, and would rather see a single source of truth used consistently across the line.
Personally, i think the use of the macros is the preferred method, because most are likely utilizing the API or web frontend to configure after initial agent installs, and don't want to have to bounce between editing the agent conf and then back to the webui, ping-ponging back and forth figuring out what is configured in which location.
Hopefully a "standard" can be agreed upon in time for 6.0, because I feel like this current setup is an impediment to new users or existing users trying to migrate to agent2, as well as a headache for day 2 operations moving forward.
Hopefully I've been able to articulate the problem as I perceive it, and also a possible remedy, or at least provoke a bit more thought towards intentionality towards the configs with agent2 moving forward.
As time has marched forward, more and more plugins are added to the agent2 release.
This is fantastic, I'm never not for this.
However, all of these keys for these plugins end up stuffed at the bottom of the agent2.conf.
If this is a fresh install, thats not really a problem.
But if I have an existing install, and I want to upgrade from a previous release, I now need to either punt on a new config from the repo which will break my install (easy and what I end up doing), or I need to meticulously merge the config on every host (not easy).
And while config management with something like salt allows me to have and push configs to all machines, I now need to go merge changes to then push out, which isn't the end of the world, but seems like it can lead to fat finger issues, etc.
What I feel like would be both easier to use and manage, is if these plugin config keys were stored in agent2.d/.
This allows more granular conf file changes when new plugins are added (just add a new conf file in agent2.d when a new plugin is added), as well as grouping things logically.
While some plugins like plugins.systemrun have one key, some plugins like ceph have 6, mysql 5, oracle 8, etc.
On top of that, on a fresh 5.0.9 agent2 install, I have plugins.docker keys both above and below the 6 ceph keys, which if I'm not looking hard, I could miss one or the other key when trying to configure docker for instance.
And to compound all of this even further, I think there is a certain level of duplicity and confusion with some of these keys too.
I know that the mysql and postgres and ceph all have locations to configure the credentials in either the agent2.conf, or using template macros, though some features only exist in the agent2.conf, and you end up with bifurcated configs.
For instance, I have my ceph-agent2 instance configured with macros, but I also need to Plugins.Ceph.InsecureSkipVerify=true, which can only be done from the config file.
Point being, I think it is extremely messy and convoluted, and would rather see a single source of truth used consistently across the line.
Personally, i think the use of the macros is the preferred method, because most are likely utilizing the API or web frontend to configure after initial agent installs, and don't want to have to bounce between editing the agent conf and then back to the webui, ping-ponging back and forth figuring out what is configured in which location.
Hopefully a "standard" can be agreed upon in time for 6.0, because I feel like this current setup is an impediment to new users or existing users trying to migrate to agent2, as well as a headache for day 2 operations moving forward.
Hopefully I've been able to articulate the problem as I perceive it, and also a possible remedy, or at least provoke a bit more thought towards intentionality towards the configs with agent2 moving forward.