This document is to serve as a running tally of how the revised version of the Weblogic module abrader/weblogic can be improved upon to provide:
- Improved usability
- Improved readability
- Complexity reduction
- Retained functionality
For the original modules by Edwin Biemond:
This document will be split into the following sections for review:
One of the easiest ways to stymie progress when using this module is to make what seems like the most innocuous changes in Hiera that will make this module fail hard and quickly.
First goal should be to separate the parameters most likely to be changed from those that are least likely to be changed and/or most likely to cause the biggest boom when altered. In my experience the following values get altered most often:
adminserver_address: "10.10.10.10"
node1_address: "10.10.10.100"
node2_address: "10.10.10.200"
domain_adminserver_address: &domain_adminserver_address "%{hiera('adminserver_address')}"
domain_node1_address: &domain_node1_address "%{hiera('node1_address')}"
domain_node2_address: &domain_node2_address "%{hiera('node2_address')}"
# global WebLogic vars
wls_oracle_base_home_dir: &wls_oracle_base_home_dir "/opt/oracle"
wls_weblogic_user: &wls_weblogic_user "weblogic"
wls_weblogic_home_dir: &wls_weblogic_home_dir "/opt/oracle/middleware11g/wlserver_10.3"
wls_middleware_home_dir: &wls_middleware_home_dir "/opt/oracle/middleware11g"
wls_version: &wls_version 1036
# global OS vars
wls_os_user: &wls_os_user "wls"
wls_os_group: &wls_os_group "dba"
wls_download_dir: &wls_download_dir "/var/tmp/install"
wls_source: &wls_source "/software"
wls_jdk_home_dir: &wls_jdk_home_dir "/usr/java/latest"
wls_log_dir: &wls_log_dir "/var/log/weblogic"
wls_domains_dir: &wls_domains_dir '/opt/oracle/wlsdomains/domains'
wls_apps_dir: &wls_apps_dir '/opt/oracle/wlsdomains/applications'
wls_jsse_enabled: true
Even this list is lengthy and further inspection to reduce this list should be evaluated.
Instance IP addresses
adminserver_address: "10.10.10.10"
node1_address: "10.10.10.100"
node2_address: "10.10.10.200"
By virtue of requiring each IP address of either the admin servers/managed nodes places an inherent dependency on Hiera anytime either type of instance is created or destroyed. This is largely limiting on how this module may behave and how it may be implemented. We should avoid such patterns in a rewrite to allow any number of managed nodes to be provisioned or destroyed without an consequence to/from the data.
Source directory for installables
wls_source: &wls_source "/software"
The fact this key/value pair exists implies that necessary installables do not reside in a repository where we would prefer them to exist and where we often instruct our customers to host such files. In the rewrite of this module if we must include such a parameter we should consider including a boolean value in the code that enables/disables this functionality for users who properly implemented binary repositories.
YAML Anchors and References
Even in my refactored version of the Hiera YAML, there are 30+ YAML anchors being referenced (i.e, any keys prefaced with an ampersand). The original module chose to keep much of the string manipulation (i.e., building absolute paths to necessary directories) inside of Hiera by appending within the YAML. Our effort should be to move any paramter manipulation into the component module and leave Hiera to host simple key/value pairs that don't require interpolation.
Large Hash Blocks
For example:
domain_instances:
'Wls1036':
domain_template: "standard"
development_mode: false
log_output: *logoutput
custom_identity: true
custom_identity_keystore_filename: '/vagrant/identity_admin.jks'
custom_identity_keystore_passphrase: 'welcome'
custom_identity_alias: 'admin'
custom_identity_privatekey_passphrase: 'welcome'
Many of these large hash blocks have repeating data values as mentioned in the previoues section (YAML Anchors and References) which points once again to the need to internalize the repeated uses and manipulations of data throughout this module.
The following are common patterns found in the original version of this module:
Definition Code in a site.pp file -> Defined Resource Type -> Resources & Templates
the other is:
Definition Code in a site.pp file -> Defined Resource Type -> Resources & Types and Providers -> Templates
In my revised version of the module I was able to refactor the process to look as such:
Role -> Profile -> Defined Resource Types -> Respective Endpoint
Even after revision, it only became clearer this module requires a rewrite.
It should be the goal of this module to evaluate all manifests to determine if they are best suited as modules or as types and providers. This is abundantly obvious on classes like orawls::domain where Exec resources are used to complete a task and the idempotent check is involved and complex. This would be far better suited as a type and provider where the idempotent check can take advantage of all that Ruby has to offer vs the limiting ability of an Exec in this regard.
For certain this module needs to have defined resource types created at a high level in order to provide the most layman user with means of deploying the pieces of Oracle Weblogic software they choose. This module as is requires a good deal of knowledge of how Puppet code is written to fully understand what someone might need to reach their end deployment goal.
Likewise as with the Manifests section, there are many Types and Providers that may be better suited as manifests split up into more cohesive resources. An example of this would be this list of templates that clearly indicates types and providers being used to populate templates. Puppet has approved methods for populating templates that doesn't require such complexity.
It is clear this module needs to be rewritten. What is also clear is work must commence on this project. This is the only way to fully understand the depth of the redevelopment of this module.
Written by: Andrew Brader - abrader
Revised by: ?
re: types and providers, I think effort spent on a generic wlst script may be useful, while it is a limited subset of Jython that is compatible (2.2) and doesn't allow us to do creative things like pass json, it would simplify the process.
For example: wlst allows us to output the states of individual resources and commands, instead of templating jython, we could just pass arguments to a jython commandline interface, so something like:
weblogic_wrapper.py server domain user pass Command Arg1 Arg2 Arg3 Arg4
http://docs.oracle.com/cd/E24329_01/web.1211/e24490/reference.htm
Also would just be a useful commandline tool to use in general, and moves us away from templating jython that is left behind on the system.