wildfly-proposals
wildfly-proposals copied to clipboard
wildfly
[WFCORE-5343]: Proposal for YAML support
I agree yaml file is easy to read. But something similar can be achieved with formatting of CLI commands. ( I know it is not yaml :) )
That's a big issue for integration into automation tools (such as Ansible). The CLI is not idempotent and thus we have customers writing pages and pages of CLI script while they could express their configuration using this feature.
I don't know of its usage outside of bootable JAR.
I'm part of an initiative to better integrate middleware products into Ansible (one use case being helping customers to replace their automation based on JON by Ansible) and this feature would help a lot. Currently, we use another tool, called JCliff, to help Ansible managed Wildfly or EAP. It's quite cumbersome and far less efficient than this feature.
Note: using JCliff forces us to deliver an extension for Ansible and maintain the associated code. With this feature, we can get ride off it and get a better performance and integration than we have currently.
The CLI is not idempotent
Can be with if conditions. But is more talkative for sure.
this feature would help a lot.
Will you expose in ansible yaml as is? Wouldn't there be any "facade" in ansible playbooks which can hide CLI talkativness? Isn't it problem for you yaml syntax is subset of CLI? Wouldn't you end in situation you will have to use CLI underneath anyway in some cases? My point is don't you need yaml have same power as CLI when used in Ansible?
@mchoma I built a prototype based on @ehsavoie work and I have yet to find a use case where I need to use the CLI directly (apart from app deployment). I simply deploy the YAML configuration as a template, so I don't really need a facade. I actually find the direct mapping between CLI syntax and the YAML very comfortable. I also think people using Ansible and used to its YAML will be happy to the template has a close syntax.
But is more talkative for sure.
I think you have largely underestimated the issue here. If I take my prototype, here is what I configured :
- adding a new JDBC driver (postgresql)
- deploying a new datasource
- configuring mod_cluster
- adding a JMS queue
- set some system properties
Pretty basic, right? With this feature, all of this is configured in one place within Ansible : the template file producing the YAML configuration. The config is loaded and executed when the server boots in a matter of milliseconds.
If the configuration evolves after the installation was performed, Ansible will detect the changes in the resulting file produced by the template, so Ansible will trigger a server restart to apply the change.
Now, let's do the same with CLI. First, I need to wrap CLI into a somewhat reusable Ansible task (akin to that), then I need to call this generic task for each item... This requires several exchanges between Ansible and the server and takes way more time than what this feature offer. And let's not even discussed what happens if one query fails and dealing with the configuration that requires the server to be reloaded...
OK, let's say you have done of all of that and that is somehow working for the installation part. Now someone comes and change the configuration. Then you need to make CLI scripts able to detect that there is a differences between the requested configuration and the state of the server....
So it's not more talkative. It's pages of custom scripts versus one configuration file. Bottom line, it's small feature for the appserver, but it's huge help for integrating Wildfly into Ansible (and other tool like Puppet or Chef).
Also I would say that the YAML is less verbose than a cli script as you only describe some configuration instead of describing the operations to be applied to create the final configuration. It is a very different perspective.
The AD is complete enough for the Jira's current state (Planning). Maybe, it would be useful to have having one little thing (backward compatibility) described - Darran has touched this topic in his commentary.
@ehsavoie WDYT?
Otherwise LGTM.
