Hi,
Adding few more details I'd like to highlight;
* - Removed Java 3rd party Puppet module dependency*
In earlier versions we used an external 3rd party Puppet module for Java
installation which we thought is not necessary anymore. Therefore we have
implemented our own Java class without any dependencies.
The only contract between Java module and WSO2 Puppet modules is it should
install Java JDK on "JAVA_HOME" path. JAVA_HOME is expected as a class
parameter by all WSO2 Puppet modules and defaults to "/opt/java". Usually
this is a symlink and actual JDK installation path may differ.
As a convenience for users we have provided a basic java class in wso2base
module which takes the JDK from Puppet file bucket, extracts it and sets
the JAVA_HOME symlink. Java class is *not *contained in any of the WSO2
Puppet module classes so it has to be added from site.pp. For eg:
## site.pp
class { 'wso2base::java' } -> class { 'wso2as' }
This offers greater flexibility for users to plug-in their own Java module.
* - Use of Puppet file server*
Earlier users had to copy jdk and product packs into respective Puppet
module's files directory. We have improved Puppet scripts to lookup in
Puppet file server path as well. For eg: packs are searched in
<PUPPET_HOME>/files/packs directory which contains packs for all the
products. This is again a convenience for the users. This applies to
patches and configs files as well.
You can try this feature with Vagrant. By default it takes Puppet file
server path as <PUPPET_HOME>/files directory and pass that as a Puppet
options parameter [1].
* - Patches structure*
With the introduction of "patch_list" parameter together with Puppet file
server support, now you do not need to copy patches to each and every
Puppet module! Patches are grouped by platform version therefore patches
dir will be as follows;
<PUPPET_HOME>/files/patches
- 4.2.0
- patch0001
...
- 4.4.0
- patch0005
...
Note that "patch_list" parameter is optional. Meaning, if you keep it empty
or undef, Puppet will copy all the patches you have placed inside
respective Puppet module's files/patches/<platform_version>/* directory.
If you set the "patch_list" as an array, it will search the Puppet file
server and Puppet module's files bucket for the specified patches. The
difference is, the latter method will error if any of the specified patches
are missing. This is useful when you want to ensure that all required
patches are copied.
[1]
https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L78
Thanks.
On Thu, Sep 8, 2016 at 5:56 AM, Akila Ravihansa Perera <[email protected]>
wrote:
> Hi Imesh,
>
>
> On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne <[email protected]> wrote:
>
>> What would be the reason for using rsync in the Vagrant setup [2]? Do we
>> update files inside the VM?
>>
>> [2] https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07d
>> ca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L53
>>
>
> We ran into an issue when mounting Hieradata folder (which is a symlink
> now) to the VM. It seems Vagrant does not fully support mounting symlinks
> so we had to rsync it.
>
> Thanks.
>
> --
> Akila Ravihansa Perera
> WSO2 Inc.; http://wso2.com/
>
> Blog: http://ravihansa3000.blogspot.com
>
--
Akila Ravihansa Perera
WSO2 Inc.; http://wso2.com/
Blog: http://ravihansa3000.blogspot.com
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
