Hi,

This is to summarize few improvements that I'd like to propose for WSO2
Puppet modules.

1. Remove conditional checks for Factor facts in the Puppet manifest.

    For eg. we do conditional check for $::vm_type factor and start the
service and configure the Cron job based on it. This is not good because
factors are unsecure and unreliable. They are being set by the target
instance running Puppet agent. This allows any node to change the factor
value and get a different Puppet catalog. Also it is hard to trace back how
a certain configuration got applied since a user would have to check couple
of places.

2. Decouple Hiera from WSO2 Puppet modules.

Sometime back we agreed to stick to Hiera but after some deep consideration
I believe we may have made some bad assumptions on this.
 - The main problem is the modules are in-charge of *how* to lookup data
instead of being *given* data. This will definitely reduce the readability
and traceability of Puppet module manifest. A user would have to go through
the Puppet code to understand what kind of data it needs. This is bad
Puppet design.

 - If a user decides to write their own Puppet module using Roles and
Profiles pattern, which would wrap the WSO2 Puppet modules, it will be
really difficult to pass data to WSO2 Puppet modules because our custom way
of handling data (Hiera lookups inside the class)

 - It makes a bad assumption that everyone uses Hiera, it is not compatible
for people who use ENCs [1]. Hiera is not the only ENC out there.

 - There's a higher barrier to entry on understanding the module, some
people would have to read the body of the module classes code to figure out
what's going on.


Therefore, I'd like to propose that we use parameterized classes to request
data instead of doing Hiera lookups inside the manifest We can still use
Hiera and pass those class parameter values via YAML data files [2]. wdyt?


[1]
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/puppet-users/DGtLs32ctjY/BULzdWSDy2MJ

[2] https://docs.puppetlabs.com/guides/external_nodes.html

Thanks.

-- 
Akila Ravihansa Perera
WSO2 Inc.;  http://wso2.com/

Blog: http://ravihansa3000.blogspot.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to