This e-mail is way too long and complicated, can you send out a YAML version of this? If any agent/feed we write uses a file like this then every agent/feed we write should use the support the same config. On 9/6/2016 6:16 PM, John Mazzitelli wrote: Some people have complained that the agent configuration file is too "complicated". Now, in defense of the agent, its configuration is nothing more than the WildFly standard configuration file (standalone.xml) that all WildFly subsystems use. Since the agent is a standard WildFly subsystem like all the rest, it uses the same configuration file like every other subsystem (which is nice, we look like any other subsystem and changes made to the agent config via the JBoss CLI are persisted for us, and the JBoss CLI can query the agent config like any other subsystem). That said, it has been suggested that we provide an "easier to understand" configuration file for those that don't know or care about the WildFly internals (say, for those that want to run the swarm agent, or those that run a standalone agent managing remote resources). So I wrote a PoC that does this. It uses YAML for a configuration file because apparently its all the rage :-) It is in this PR: https://github.com/hawkular/hawkular-agent/pull/250 A sample config file could look like this: ======== subsystem: enabled: true storage-adapter: url: http://localhost:8080 tenant-id: hawkular username: jdoe password: password managed-servers: remote-dmr: - name: My WildFly enabled: true host: my-host port: 9999 username: admin password: wotgorilla? ======== Some things to note (many of these need to be addressed if this feature is to get merged into master): 1. Not all the things you can configure in standalone.xml you can configure in the yaml. No metric types, resource types, etc. are configurable (though I may need to change this for the JMX stuff because the JMX resource types are not "hard-codable" like the WildFly ones simply because we don't know what MBeans people want to monitor). Of course, the more I make the yaml look like standalone.xml, the more it becomes just as complicated and defeats the purpose. 2. Right now the yaml is read-only. If, for example, you go through the JBoss CLI and enable a disabled managed server or you create a new one (like a new wildfly endpoint) nothing gets written out to the yaml. This is because all the wiring in WildFly Server and the JBoss CLI touches standalone.xml as this is the way things were designed to work inside of WildFly subsystems (WildFly does not want subsystems to have their own external config files - we are going against the design philosophy of the WildFly architecture here). This is not a problem for the swarm-based agent because its standalone.xml-based agent config is already read-only - so there is no difference there. 2a. Not only that, but since the JBoss CLI reads data that ultimately comes from the standalone.xml, it currently will not reflect any data found in the yaml. Again, because Swarm agent doesn't support the JBoss CLI anyway, its a moot point for the swarm agent. 3. Security concerns are for the most part ignored in this PoC. 3a. See the password in clear text? We do not have access to the WildFly vault like we would if we put this configuration in standalone.xml. The agent can encrypt passwords in its configuration, but only if you use standalone.xml for that config (because we just rely on WildFly's vault feature). If you put the config in the external yaml config, we lose that functionality. If we want obfuscation, we have to write our own mechanism and ask people to manage it using the agent's own tools (like we would have to provide a tool to encrypt agent passwords for users to use). (caveat: I don't know if it is possible, but we can look into how the vault works and maybe the agent can make internal API calls to take encrypted text from the yaml and request its decrypted value from the vault? Would need to research this possibility). 3b. WildFly provides the ability to configure "security realms" and allow subsystems to share those realms. This gives subsystems access to keystores and truststores configured in WildFly Server' security realms. These security realms are configured in standalone.xml. There is no such configuration in the yaml - in order to define security realms you need to do it in standalone.xml (these security realm definitions are their own section in standalone.xml, outside of any subsystem config - this is why they are not in the yaml, because they are WildFly configuration settings, not agent configuration). Can we define our own keystore and truststore config settings in the yaml? Yes, probably. But this would be outside of the WildFly standard config and I'm not sure how easily implemented this would be. This is, again, something that needs to be researched. 4. Right now there are no JMX endpoints configurable in the yaml - it only supports local-dmr, remote-dmr, and remote-prometheus. Its doable, but for the PoC I limited the work to include only WildFly servers and Prometheus servers to be configurable in the yaml. 5. The yaml is actually an overlay - for example, if the <subsystem> entry in standalone shows "enabled=true" but the yaml shows "enabled=false" the yaml is overlayed on top of standalone.xml (thus the yaml enabled=false takes effect). If the yaml defines a remote-dmr with name "Foo" and standalone.xml defines a remote-dmr with the same name, the yaml overrides the standalone.xml (any settings in the yaml take effect; if a setting is not in the yaml but is in the standalone.xml, that setting from standalone.xml takes effect). That is all. Just wanted to bring this up, let people know that we can have a "simpler" agent configuration (with limitations as described above), if we so choose. This is not going to be merged without a more in-depth discussion to see if people really want it and if we really want to support this (it adds some complexity to the implementation, and if we are to work around some of the limitations, more complexity will be introduced). _______________________________________________ hawkular-dev mailing listhawkular-dev(a)lists.jboss.org <javascript:_e(%7B%7D,'cvml','hawkular-dev@lists.jboss.org');>https://lists.jboss.org/mailman/listinfo/hawkular-dev

> What about an utility to export/import that yaml from/to the standard > configuration file (standalone.xml) ? That is one idea. However, note there still would be issues that need to be solved: 1) Any change you make to the yaml file would require the user to run the export/import tool again - is that going to be annoying to the user? Are they even going to know they have to run a tool after editing a configuration file? That seems to be annoying to add a second step (1. modify the yaml file 2) run a tool to export the config into standalone.xml). People will most likely forget to do 2.

2) This means our export/import tool needs to be smart enough to know how to transform the standalone.xml when the agent configuration is not there yet AND when there is already agent configuration there. We'd need to do something similar to what the agent installer does, which is not trivial. 3) Still doesn't solve the security problems (passwords unencrypted, how to define and reference security realms) - unless we add the security realms in the yaml and have the export/import tool modify the standalone.xml so it modifies the proper security-realms section in standalone xml, too. 4) Still doesn't solve the "no write-back" to the yaml. If you change or add a config setting via the JBoss CLI, it will get persisted to standalone.xml, but it will NOT be persisted to the yaml file. The yaml file essentially becomes stale and you can no longer refer to it and be guaranteed it contains the most up-to-date config. If you run the export/import tool on the stale yaml, you have essentially overwritten the current config in standalone.xml with stale config.

hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev