Re: [Dev] [puppet] Setting up puppet home from script

[Akila Ravihansa Perera]

>>> 7. Create a symlink to wso2 hiera-files.
>>>>>>>
>>>>>>>>   /wso2/hieradata/dev/wso2/wso2 ->
>>>>>>>> ../hieradata/dev/wso2/
>>>>>>>
>>>>>>>
>>>>>>> Once the setup.sh completes, users can copy product pack and jdk
>>>>>>> distribution for relevant folders and run vagrant setup against
>>>>>>> above-created puppet home.
>>>>>>>
>>>>>>> We are planning to automate the copying of product pack, jdk
>>>>>>> distribution and starting vagrant setup as well.
>>>>>>>
>>>>>>> Setup.sh can be found at [1]. Please share your suggestions towards
>>>>>>> this approach.
>>>>>>>
>>>>>>> [1] https://github.com/wso2/puppet-common/blob/master/setup.sh
>>>>>>>
>>>>>>> --
>>>>>>> *Thanks and Regards,*
>>>>>>> Anuruddha Lanka Liyanarachchi
>>>>>>> Software Engineer - WSO2
>>>>>>> Mobile : +94 (0) 712762611
>>>>>>> Tel  : +94 112 145 345
>>>>>>> a <thili...@wso2.com>nurudd...@wso2.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Imesh Gunaratne*
>>>>>> Software Architect
>>>>>> WSO2 Inc: http://wso2.com
>>>>>> T: +94 11 214 5345 M: +94 77 374 2057
>>>>>> W: https://medium.com/@imesh TW: @imesh
>>>>>> lean. enterprise. middleware
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Thanks and Regards,*
>>>>> Anuruddha Lanka Liyanarachchi
>>>>> Software Engineer - WSO2
>>>>> Mobile : +94 (0) 712762611
>>>>> Tel  : +94 112 145 345
>>>>> a <thili...@wso2.com>nurudd...@wso2.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Imesh Gunaratne*
>>>> Software Architect
>>>> WSO2 Inc: http://wso2.com
>>>> T: +94 11 214 5345 M: +94 77 374 2057
>>>> W: https://medium.com/@imesh TW: @imesh
>>>> lean. enterprise. middleware
>>>>
>>>>
>>>
>>>
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a <thili...@wso2.com>nurudd...@wso2.com
>



-- 
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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi Pubudu,

That feature is still available but moved to install stage (install.pp),
because all the resources in configure stage depend on that.

Thanks.

On Thursday, 8 September 2016, Pubudu Gunatilaka <pubu...@wso2.com> wrote:

> Hi Akila,
>
> In puppet modules 2.1.0 release we had the capability to create
> directories for a given folder structure [1] and it has used in some
> products [2]. In latest puppet changes I could not find that option except
> the directory list value [3]. Did we remove that feature on purpose? If not
> shall we add that?
>
> [1] - https://github.com/wso2/puppet-modules/blob/master/
> modules/wso2base/manifests/configure.pp#L19
> [2] - https://github.com/wso2/puppet-modules/blob/master/
> hieradata/dev/wso2/wso2das/3.0.1/mesos/default.yaml#L44
> [3] - https://github.com/wso2/puppet-base/blob/master/
> manifests/configure.pp#L21
>
> Thank you!
>
> On Thu, Sep 8, 2016 at 6:23 AM, Akila Ravihansa Perera <raviha...@wso2.com
> <javascript:_e(%7B%7D,'cvml','raviha...@wso2.com');>> wrote:
>
>> 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
>> /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 /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;
>>
>> /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//* 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/56b34c4c2db11
>> f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L78
>>
>> Thanks.
>>
>>
>> On Thu, Sep 8, 2016 at 5:56 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com <javascript:_e(%7B%7D,'cvml','raviha...@wso2.com');>>
>> wrote:
>>
>>> Hi Imesh,
>>>
>>>
>>> On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne <im...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','im...@wso2.com');>> 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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

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
/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 /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;

/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//* 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 <raviha...@wso2.com>
wrote:

> Hi Imesh,
>
>
> On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne <im...@wso2.com> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi Imesh,


On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne <im...@wso2.com> 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/
> 56b34c4c2db11f07dca739f0e92bf1d955cfcb46/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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi,

This thread is to raise awareness around some of the implementation level
decisions that were taken when refactoring Puppet modules and splitting
them into their own respective GitHub repos.

* - Decouple Hiera from Puppet modules*
In last Puppet-Modules release Hiera lookups were done in /manifests/init.pp which made it mandatory for users to use Hiera.
As part of the refactoring Hiera is made optional and configuration
parameters are defined as class parameters which can be passed by site.pp


* - Use Hiera only as a data store*
There were some discussions about creating hooks in Puppet manifest to
which Puppet resources can be plugged in via Hiera data. However, going
forward we have come to a conclusion that Hiera should only be used as a
data store and nothing more. Any customizations to Puppet manifest can be
done directly in init.pp.

* - Break Puppet configurations into stages*
We have identified following stages which can be considered completely
independent from each other;
system - set operating system configs, install packages etc.
clean - remove any existing installation
install - extract the pack and set user permissions
configure - populate templates, copy config files, import certs
service - start the service

Here is a snippet of wso2as/manifests/init.pp

contain wso2base
contain wso2base::system
contain wso2base::clean
contain wso2base::install
contain wso2base::configure
contain wso2base::service

Class['::wso2base'] -> Class['::wso2base::system']
-> Class['::wso2base::clean'] -> Class['::wso2base::install']
-> Class['::wso2base::configure'] ~> Class['::wso2base::service']

As you can see Puppet class containment [1] is used to ensure the
dependency ordering. This is useful when users combine WSO2 Puppet modules
with other modules (for eg: when creating roles and profiles).

* - Remove inter module class inheritance*
As per official Puppet docs class inheritance is to be avoided whenever
possible [2]. Considering this we have removed all such relationships
except for params.pp which contains default values.

* - Move default values to params.pp and remove wso2base/params.pp*
After giving much thought, we decided to keep default values in
/manifests/params.pp and only in that place. Having common
default values in /manifests/params.pp would minimize duplication
but would be less readable for end users. Therefore we have come to a
conclusion that wso2base module should only be used as a common
resources/classes pool. It should not contain any data.

*Try it out!*

1. Git clone https://github.com/wso2/puppet-common
2. Run puppet-common/setup.sh -p as
3. Goto puppet-common/vagrant
4. Run vagrant up


[1]
https://docs.puppet.com/puppet/latest/reference/lang_containment.html#containing-classes
[2] https://docs.puppet.com/guides/style_guide.html#class-inheritance

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

[Dev] [Puppet] Way forward with WSO2 Puppet modules

[Akila Ravihansa Perera]

Hi,

We have already created separate GitHub repos for Puppet modules so that
the Puppet module can be shipped as part of a product release. All common
resources and classes are still in wso2base Puppet module. We have
refactored the module structure which I'll highlight below;

Please refer to wso2base module [1] and  wso2as module [2] which we have
implemented as a reference. We will discuss any improvements needed and
replicate the same structure for other modules.

 - No more Hiera lookups in init.pp
   All Hiera lookups have been moved to params classes in wso2base and
product module. All common parameters across products are defined in
wso2base/params.pp and product specific ones are defined in corresponding
product Puppet module

 - Do Hiera lookups only when enabled via a facter
   wso2base/params.pp lookup a facter named "use_hieradata" and decide
whether to take default values defined directly in params.pp or to perform
Hiera lookups. It would have been ideal if Hiera lookups are all done in a
separate layer (for eg: using roles and profiles pattern), but one problem
is users will have to write their own profiles module to use Hiera.
Maintaining profiles in our side would be an overhead. This is still open
to suggestions.

 - Class parameters to override defaults in params.pp
   Earlier Puppet modules were tightly coupled with Hiera so that users
were unable to simply include the module from site.pp and run it. Now all
the variables are defined as class parameters which takes common values
from wso2base/params.pp [4]. Default values for any product specific
parameters are kept in /params.pp. For eg: [5]

Any user can now simply do the following in site.pp

class java -> class wso2as

Above manifest will configure wso2as using default configuration (vanilla
pack). Default values can be overridden by passing values. For eg: to set a
port offset of 10

$ports = {
offset => 10
}
class java ->
class  { 'wso2as':
   ports => $ports
}

 - Class dependencies and containment
  All base classes are contained in product module main class to enforce
the class dependency order [6].

 - Data type validation
   To enforce that parameters passed are in expected format and to help
with troubleshooting we have added validations in wso2base module which
checks whether data types passed for each parameter is correct [7].

 - Vagrant setup
   We have moved out the Vagrantfile, site.pp and hiera.yaml files to a
separate repo named "puppet-commons" [3]. This repo will contain any Puppet
related artifact which does not belong to a Puppet module. It has a
setup.sh shell script to create the PUPPET_HOME directly by cloning Puppet
module GitHub repos and merging Hieradata. Details about this setup.sh
script will be discussed in a separate thread.

Any developer who wants to try out a Puppet module can do so by performing
following steps;
1. Git clone puppet-commons
2. Run setup.sh
3. Provide PUPPET_HOME when prompted by setup.sh
4. Provide JDK file location product pack location when prompted
5. Goto puppet-commons/vagrant
6. Run vagrant up

Note that we have not fully implemented the end-to-end flow yet.

[1] https://github.com/wso2/puppet-base
[2] https://github.com/wso2/puppet-as
[3] https://github.com/wso2/puppet-commons
[4] https://github.com/wso2/puppet-base/blob/master/manifests/params.pp
[5] https://github.com/wso2/puppet-as/blob/master/manifests/params.pp#L29
[6] https://github.com/wso2/puppet-as/blob/master/manifests/init.pp#L115
[7]
https://github.com/wso2/puppet-base/blob/master/manifests/init.pp#L55-L86

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

Re: [Dev] Hieradata location for puppet modules

[Akila Ravihansa Perera]

Hi,

There is one catch with option 2; we need to track which Hiera distribution
(in platform specific artifacts repo) goes with which Puppet release. This
won't be a big issue but just wanted point out.

Thanks.

On Fri, Aug 26, 2016 at 9:05 AM, Rasanjaya Subasinghe <rasanj...@wso2.com>
wrote:

> Hi all,
>
> The option 2 would be good for do the MC deployment. And other users  can
> be used default profile with released puppet forge module.
>
> Thanks
>
>
> On Thursday, August 25, 2016, Anuruddha Liyanarachchi <anurudd...@wso2.com>
> wrote:
>
>> Hi Devs,
>>
>> We are in the process of restructuring and splitting the puppet modules
>> per product. As per the initial discussions, we have created separate
>> repositories per product puppet module and one common repository for puppet
>> base module.
>>
>> In order to publish puppet modules to puppet forge, we have decoupled
>> hieradata from puppet modules using profiles. Now the puppet modules are
>> capable of running without hieradata for the default profile.
>>
>> However, it is easier to do deployment using hieradata. The intention of
>> this mail is to discuss and finalize hieradata location.
>>
>> Appreciate your feedback on selecting an available option.
>>
>> Following are the available options:
>>
>> *1. Use one repository to keep all product hieradata.*
>> Pros:
>> - Easy to manage since all the hieradata are in one place.
>> - No data duplication
>>
>> Cons:
>> - Releasing hieradata with a product is not possible.
>> - Difficult to track changes.
>>
>>
>> *2. Keep hieradata with platform specific artifact repositories.
>> (kubernetes, mesos )*
>> Pros:
>> - Hieradata can be released with a product.
>>
>> Cons:
>> - Possible data duplication.
>> - Hieradata is a part of puppet and it is not related to mesos or
>> kubernetes
>> - Have to create repositories to store default hieradata.
>>
>>
>> *3. Create separate repositories per product to store hieradata. *
>> Pros:
>> - Product level hieradata separation.
>> - Easier to release and track changes.
>>
>> Cons:
>> - No of repositories are high.
>> - User experience will be not good as users will have to clone from
>> multiple locations.
>>
>>
>>
>> *4. Keep hieradata in the product puppet module repos with
>> .pmtignore file. *Pros:
>> - Minimum changes required.
>> - Can be released with product puppet modules.
>>
>> Cons:
>> - Most of the puppet repos don't contain hieradata
>> - Puppet recommends keeping  hieradata separately from modules.
>>
>>
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> anurudd...@wso2.com
>>
>
>
> --
> -
> Rasanjaya Subasinghe
> Software Engineer, Dev/Ops, WSO2 Inc.
> +94772250358
> rasanj...@wso2.com
>
>


-- 
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

[Dev] [Mesos artifacts] Use Docker --dns and --dns-search for hostname DNS resolution

[Akila Ravihansa Perera]

Hi,

Currently we are using Marathon-LB hostname and service ports in product
configuration when deploying on DC/OS (Apache Mesos). We can set the
--dns-search and --dns properties and set a DOMAIN and DNS server in
/etc/resolve.conf to resolve hostnames which are not found in /etc/hosts
[1].

This is a much cleaner approach than using Marathon-LB hostname and service
ports. WDYT?


[1] https://docs.docker.com/v1.7/articles/networking/#dns

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

[Dev] [msf4j] Microservices running on multiple transports in the same application

[Akila Ravihansa Perera]

Hi,

I tried to create multiple MicroservicesRunner objects on different ports
as follows;

public class Application {
public static void main(String[] args) {

new MicroservicesRunner()
.addExceptionMapper(new EntityNotFoundMapper(), new
CustomerNotFoundMapper())
.deploy(new CustomerService())
.start();

new MicroservicesRunner(8081)
.addExceptionMapper(new EntityNotFoundMapper(), new
InvoiceNotFoundMapper())
.deploy(new InvoiceService())
.start();
}
}


Looks like this is not supported. I'm getting "Problem accessing:
/customer/XXX. Reason: Not Found" error.

It fails because NettyTransportContextHolder is a singleton. Therefore
messing up MSF4J message handlers. Is this by design? If so shouldn't we
print a warning if a developer tries to do this?

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

[Dev] Expose a health check endpoint in WSO2 products

[Akila Ravihansa Perera]

Hi,

Having a product specific health check endpoint would help deployments in
platforms like Kubernetes, DockerSwarm, Mesos etc. in which we can
configure a health check. The deployment platform will call to this
endpoint to query the status of the deployed service and re-spin the
instances if they are not healthy for a given period of time.

 It is basically another REST API service when queried will return HTTP
status code in the range of 200-300 if the internal components are
operating as expected.
For eg. in case of API-Gateway this can be an embedded dummy API so that we
can make sure Synapse transport is up and running. In case of
Identity-Server we can check the connection to userstores/DBs and expose
the status as a REST API.

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

Re: [Dev] [VOTE] Release WSO2 Mesos Artifacts 1.0.0 RC1

[Akila Ravihansa Perera]

Verified the following:

 - License headers using RAT plugin
 - Checked distribution structure
 - Tested wso2bps 3.5.1 distributed deployment
 - Tested wso2am with IS as KM pattern

[x] - Stable, go ahead and release



On Mon, Aug 1, 2016 at 5:03 PM, Isuru Haththotuwa <isu...@wso2.com> wrote:

> Verified the following:
>
>1. License headers using RAT plugin
>2. Tested the following on mesos:
>- wso2am 1.10.0 - standalone and distributed deployments
>   - wso2das 3.0.1 - standalone and distributed deployments
>   - wso2cep 4.0.0 - standalone deployment with a smoke test
>
> *[x] - Stable, go ahead and release*
>
> On Tue, Jul 26, 2016 at 11:28 PM, Pubudu Gunatilaka <pubu...@wso2.com>
> wrote:
>
>> Hi Devs,
>>
>> This is the first release candidate (RC1) of WSO2 Mesos Artifacts 1.0.0.
>>
>> Please download, test and vote. Please refer the README files under each
>> product for details on testing the artifacts.
>>
>> Source & binary distribution files:
>> https://github.com/wso2/mesos-artifacts/releases/tag/v1.0.0-rc1
>>
>> Maven staging repo:
>>
>> https://maven.wso2.org/nexus/content/repositories/orgwso2carbonmesosartifacts-1000/
>>
>> The tag to be voted upon:
>> https://github.com/wso2/mesos-artifacts/releases/tag/v1.0.0-rc1
>>
>> Mesos Artifacts Documentation:
>> https://docs.wso2.com/display/MA100/Home
>>
>> This vote will be open for 72 hours or as needed.
>>
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>>
>> Regards,
>> WSO2 PaaS team
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [VOTE] Release WSO2 Puppet Modules 2.1.0 RC2

[Akila Ravihansa Perera]

Verified the following:

   1. License validity with the RAT plugin
   2. Built and tested Docker images for all products
   3. Tested and verified WSO2 APIM 1.10.0 in Vagrant setup

*[x] Stable - go ahead and release*

On Thu, Jul 28, 2016 at 12:10 PM, Isuru Haththotuwa <isu...@wso2.com> wrote:

> Verified the following:
>
>1. License validity with the RAT plugin
>2. provisioned APIM 1.10.0, DAS 3.0.1 with vagrant setup and ran a
>smoke test
>3. Built the following Docker images with puppet provisioning using
>the puppet modules from the tag v2.1.0-rc2, and ran a smoke test
>   - ESB 4.9.0
>   - CEP 4.0.0
>   - MB 3.1.0
>   - DSS 3.5.0
>   - GREG 5.1.0
>
> *[x] Stable - go ahead and release*
>
> On Tue, Jul 26, 2016 at 2:07 PM, Thanuja Uruththirakodeeswaran <
> thanu...@wso2.com> wrote:
>
>> [+1] Stable - Go ahead and release
>>
>> Verified the following:
>>
>>1. Distribution
>>2. License Headers using RAT plugin
>>3. README files
>>4. Verified following products with docker images built with puppet
>>provisioning for Mesos platform and tested basic functionalities:
>>
>>
>>- WSO2 ES 2.0.0 (Distributed setup)
>>- WSO2 AS 5.3.0 (Distributed setup)
>>- WSO2 ESB 4.9.0 (Distributed setup)
>>- WSO2 MB 3.1.0
>>- WSO2 IS 5.1.0
>>- WSO2 IS KM 5.1.0
>>- WSO2 APIM 1.10.0
>>
>> 5. Tested above products in Mesos platform with secure vault
>> enabled.
>> 6. Tested SSO configuration with WSO2 IS 5.1.0 as identity
>> provider and WSO2 ESB 4.9.0 and WSO2 AS 5.3.0 as service providers.
>>
>> Thanks.
>>
>> On Mon, Jul 25, 2016 at 6:39 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> This is the second release candidate (RC2) of WSO2 Puppet Modules 2.1.0
>>> release. Please download, verify, and vote. Voting will be open for 72
>>> hours or as needed.
>>>
>>> This release fixes following issues:
>>> https://wso2.org/jira/browse/PMODULES-16?filter=13155
>>>
>>> ​Source and binary distribution files:
>>> https://github.com/wso2/puppet-modules/releases/tag/v2.1.0-rc2
>>>
>>> The tag to be voted upon:
>>> https://github.com/wso2/puppet-modules/releases/tag/v2.1.0-rc2
>>>
>>> Release verification guide:
>>>
>>> https://docs.wso2.com/display/PM210/Setting+up+the+Development+Environment
>>>
>>> Refer modules README files for more details.
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-]  Broken - do not release (please explain why)
>>>
>>> Thank you,
>>> WSO2 PaaS Team.
>>>
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thanuja Uruththirakodeeswaran
>> Software Engineer
>> WSO2 Inc.;http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 774363167
>>
>> <http://wso2.com/signature>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [VOTE] Release WSO2 Dockerfiles 1.2.0 RC1

[Akila Ravihansa Perera]

[+1] Stable - Go ahead and release

1. Verified the License Headers with RAT Tool.
2. Checked distribution.
3. Tested wso2esb-4.9.0 using default and puppet provisioning

On Tue, Jul 26, 2016 at 11:17 AM, Anuruddha Liyanarachchi <
anurudd...@wso2.com> wrote:

> Hi All,
>
> I have tested the following.
>
> 1. Verified the License Headers with RAT Tool.
> 2. Checked distribution.
> 3. Test following product with puppet provisioning.
>
>- APIM 1.10.0
>- AS 5.3.0
>- BPS 3.5.0
>- BRS 2.2.0
>- CEP 4.0.0
>
>
>
> On Tue, Jul 26, 2016 at 11:14 AM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> Hi All,
>>
>> I have tested the following.
>>
>> 1. Verified the License Headers with RAT Tool.
>> 2. Checked distribution.
>> 3. Test following product with puppet provisioning.
>>
>>
>>
>> On Mon, Jul 25, 2016 at 10:30 PM, Thanuja Uruththirakodeeswaran <
>> thanu...@wso2.com> wrote:
>>
>>> [+1] Stable - Go ahead and release
>>>
>>> Verified the following:
>>> 1. Distribution
>>> 2. License Headers
>>> 3. Built following products docker images with puppet provisioning for
>>> Mesos platform and tested basic functionalities:
>>>
>>>
>>>- WSO2 ES 2.0.0 (Distributed setup)
>>>-  WSO2 ESB 4.9.0 (Distributed setup)
>>>-  WSO2 MB 3.1.0
>>>-  WSO2 IS 5.1.0
>>>-  WSO2 IS KM 5.1.0
>>>
>>> Thanks.
>>>
>>> On Fri, Jul 22, 2016 at 9:27 PM, Anuruddha Liyanarachchi <
>>> anurudd...@wso2.com> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> This is the first release candidate (RC1) of WSO2 Dockerfiles 1.2.0
>>>> release.
>>>>
>>>> *This release fixes the following issues:*
>>>>
>>>> https://wso2.org/jira/issues/?filter=13159
>>>>
>>>> *Tag to be voted upon:*
>>>>
>>>> https://github.com/wso2/dockerfiles/tree/v1.2.0-rc1
>>>>
>>>> *Source and distribution packages:*
>>>>
>>>> https://github.com/wso2/dockerfiles/releases/tag/v1.2.0-rc1
>>>>
>>>> Please download, test, and vote. The README file under the distribution
>>>> contains guide and instructions on how to try it out locally.
>>>>
>>>> [+] Stable - Go ahead and release
>>>>
>>>> [-] Broken - Do not release (explain why)
>>>>
>>>>
>>>>
>>>> This vote will be open for 72 hours or as needed.
>>>>
>>>> Regards,
>>>> WSO2 PaaS team
>>>>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanuja Uruththirakodeeswaran
>>> Software Engineer
>>> WSO2 Inc.;http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 774363167
>>>
>>> <http://wso2.com/signature>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> a <thili...@wso2.com>nurudd...@wso2.com
>>
>
>
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a <thili...@wso2.com>nurudd...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [VOTE] Release WSO2 Dockerfiles 1.2.0 RC1

[Akila Ravihansa Perera]

Hi Anuruddha,

The pom version in master branch should always be a SNAPSHOT version [1].

Thanks.

On Fri, Jul 22, 2016 at 9:27 PM, Anuruddha Liyanarachchi <
anurudd...@wso2.com> wrote:

> Hi Devs,
>
> This is the first release candidate (RC1) of WSO2 Dockerfiles 1.2.0
> release.
>
> *This release fixes the following issues:*
>
> https://wso2.org/jira/issues/?filter=13159
>
> *Tag to be voted upon:*
>
> https://github.com/wso2/dockerfiles/tree/v1.2.0-rc1
>
> *Source and distribution packages:*
>
> https://github.com/wso2/dockerfiles/releases/tag/v1.2.0-rc1
>
> Please download, test, and vote. The README file under the distribution
> contains guide and instructions on how to try it out locally.
>
> [+] Stable - Go ahead and release
>
> [-] Broken - Do not release (explain why)
>
>
>
> This vote will be open for 72 hours or as needed.
>
> Regards,
> WSO2 PaaS team
>
>
> _______
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [VOTE] Release WSO2 Puppet Modules 2.1.0 RC1

[Akila Ravihansa Perera]

Hi Pubudu,

The pom version in master branch should always be a SNAPSHOT version [1].

[1] https://github.com/wso2/puppet-modules/blob/master/pom.xml#L24

Thanks.

On Fri, Jul 22, 2016 at 10:04 PM, Pubudu Gunatilaka <pubu...@wso2.com>
wrote:

> Hi Devs,
>
> This is the first release candidate (RC1) of WSO2 Puppet Modules 2.1.0
> release. Please download, verify, and vote. Voting will be open for 72
> hours or as needed.
>
> This release fixes following issues:
>
> https://wso2.org/jira/browse/PMODULES-16?filter=13155
>
> ​Source and binary distribution files:
>
> https://github.com/wso2/puppet-modules/releases/tag/v2.1.0-rc1
>
> The tag to be voted upon:
>
> https://github.com/wso2/puppet-modules/releases/tag/v2.1.0-rc1
>
> Release verification guide:
>
> https://docs.wso2.com/display/PM210/Setting+up+the+Development+Environment
>
> Refer modules README files for more details.
>
> Please vote as follows.
>
> [+] Stable - go ahead and release
>
> [-]  Broken - do not release (please explain why)
>
> Thank you,
> WSO2 PaaS Team.
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> _______
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] Problem when resolving Puppet Master from Agent

[Akila Ravihansa Perera]

Hi Isuru,

This was very recently fixed in master branch. Earlier we had a template
for /etc/hosts which would not only overwrite the entries but also make it
platform dependent. Now we have switched to Puppet "host" resource type
which handles platform specific configuration.

Thanks.

On Fri, Jul 22, 2016 at 3:29 PM, Isuru Perera <isu...@wso2.com> wrote:

> Hi,
>
> I recently tried deploying WSO2 IS 5.1.0 using Puppet [1] and I followed
> the guide in wiki [2].
>
> I used two VMs (created by Vagrant) for Master and Agent. When I run the
> puppet agent, it overwrites the /etc/hosts entry added to Puppet Master
> [3]. After that the puppet agent fails.
>
> Could you please check the guide again?
>
> Thanks!
>
> Best Regards,
>
> [1] https://github.com/wso2/puppet-modules
> [2]
> https://github.com/wso2/puppet-modules/wiki/Use-WSO2-Puppet-Modules-in-puppet-master-agent-Environment
> [3]
> https://github.com/wso2/puppet-modules/wiki/Use-WSO2-Puppet-Modules-in-puppet-master-agent-Environment#212-puppet-agent
>
> --
> Isuru Perera
> Associate Technical Lead | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
> Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about>
>



-- 
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

Re: [Dev] [Puppet Modules] AWS Membership Scheme Configuration Support

[Akila Ravihansa Perera]

Hi Rasanjaya,

Yes, but those you mentioned may not be the only case where we need to
restart the server. If a lib file is copied or removed that will need a
restart as well. But for some files that may not be needed.

Previously how did you track whether new patches were applied or existing
patches were removed from Puppet side? Do we have to specify each patch
number in Puppet manifest or Hiera?

Thanks.

On Fri, Jul 22, 2016 at 2:17 PM, Rasanjaya Subasinghe <rasanj...@wso2.com>
wrote:

> Hi all,
>
> In general, we can use a bash Init file to maintain the wso2 server state,
> which file is supposed to start, stop and restart the wso2 service based on
> the configuration change on the master side. We can notify the service unit
> file, though puppet relationship to restart the service for any template
> change or new patch.
>
> Thanks
>
> On Fri, Jul 22, 2016 at 1:24 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>>
>>> 3. Each and every time the config file change [Ex: axis2.xml] product
>>>> gets deleted and start with the fresh configuration.
>>>>
>>>
>>> ​Agree! It should not start from the beginning for a configuration
>>> change.
>>>
>>
>> This is now fixed in master branch. Basically Puppet runs in "refresh"
>> mode by default. It will kill any running WSO2 process before applying
>> configurations but will use the same pack if it has been already downloaded
>> from Puppet master. Also it will apply new configurations on top of
>> previous installation if it exists. You can control this behavior by
>> setting "wso2::maintenance_mode" Hiera property. If you set it to "new"
>> then any previous installation will be cleaned first; "zero" will clean the
>> pack as well.
>>
>> However, we still need to improve on how product server is restarted;
>> i.e. the server should be restarted only if there has been a change applied
>> to template, patch list is updated, lib files are updated etc. But I don't
>> think we can reliably detect (from Puppet side) whether server should be
>> restarted or not. Perhaps a template change may not need a restart. So IMO,
>> it's better to restart the server on every Puppet run. Any thoughts?
>>
>> Thanks.
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> --
> Rasanjaya Subasinghe
> Software Engineer, Dev/Ops , WSO2 inc(Sri Lanka)
> +94772250358
> rasanj...@wso2.com
>



-- 
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

Re: [Dev] [Puppet Modules] AWS Membership Scheme Configuration Support

[Akila Ravihansa Perera]

Hi,


> 3. Each and every time the config file change [Ex: axis2.xml] product gets
>> deleted and start with the fresh configuration.
>>
>
> ​Agree! It should not start from the beginning for a configuration change.
>

This is now fixed in master branch. Basically Puppet runs in "refresh" mode
by default. It will kill any running WSO2 process before applying
configurations but will use the same pack if it has been already downloaded
from Puppet master. Also it will apply new configurations on top of
previous installation if it exists. You can control this behavior by
setting "wso2::maintenance_mode" Hiera property. If you set it to "new"
then any previous installation will be cleaned first; "zero" will clean the
pack as well.

However, we still need to improve on how product server is restarted; i.e.
the server should be restarted only if there has been a change applied to
template, patch list is updated, lib files are updated etc. But I don't
think we can reliably detect (from Puppet side) whether server should be
restarted or not. Perhaps a template change may not need a restart. So IMO,
it's better to restart the server on every Puppet run. Any thoughts?

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

Re: [Dev] Shipping marathon-lb docker image with mesos artifacts

[Akila Ravihansa Perera]

Hi Anuruddha,

Great work in patching Marathon-lb to work with WSO2 products! Ideally this
should be fixed in the upstream project otherwise maintenance will be a
problem. Shall we create a issue in Marathon-lb project and send a PR?

Thanks.

On Thu, Jul 21, 2016 at 5:24 PM, Anuruddha Liyanarachchi <
anurudd...@wso2.com> wrote:

> Hi All,
>
> By default marathon-lb blocks  TLS 1.0  protocol [1].
>
>> ssl-default-bind-options no-sslv3 no-tlsv10 no-tls-tickets
>>
>> Since wso2am uses TLS v1.0.0, users are unable to login to api-manager
> publisher ui when sticky sessions are enabled.
>
> In order to sticky session to work with wso2am and jdk 1.7.*,  we need to
> enable TLS V1.0.0 in marathon_lb template. Also marathon-lb certificate
> should be added to client-trust-store of wso2server.
>
> As a solution I have created a customized wso2/marathon-lb docker image
> which has pre loaded with a self signed certificate [2]. This certificate
> is added to client trust-store via puppet [3]. In production this
> certificate can be replaced and configure with a proper certificate.
>
> I have pushed the customized docker image to docker hub
> (wso2/marathon-lb:v1.3.1) and changed wso2-mesos-artifacts to use
> customized image.
>
>
> [1] https://github.com/mesosphere/marathon-lb/blob/master/config.py#L56
> [2]
> https://github.com/wso2/mesos-artifacts/tree/master/common/marathon-lb/docker
> [3]
> https://github.com/wso2/puppet-modules/blob/master/modules/wso2base/manifests/import_cert.pp
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a <thili...@wso2.com>nurudd...@wso2.com
>



-- 
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

Re: [Dev] Adding SVN dockerfiles to wso2/dockerfiles

[Akila Ravihansa Perera]

Hi Pubudu,

True, but this image will not be built regularly right? Once we push to
DockerHub users can pull instead of building?

Thanks.

On Thursday, 21 July 2016, Imesh Gunaratne <im...@wso2.com> wrote:

>
>
> On Thu, Jul 21, 2016 at 10:31 AM, Pubudu Gunatilaka <pubu...@wso2.com
> <javascript:_e(%7B%7D,'cvml','pubu...@wso2.com');>> wrote:
>
>> Hi Akila,
>>
>> I used the base image to get rid of running apt-get update again for svn
>> docker image. Apt-get update takes time and also sometimes it fails as
>> well.
>>
>> I have already created Mesos artifacts for svn in [1] and will push those
>> changes to Mesos artifact repo. Will work on the Kubernetes artifacts.
>>
>
> ​May be we can first focus on Mesos artifacts. Will add this to K8S
> artifacts later on. Might be better to track it in JIRA.
>
> Thanks​
>
>
>>
>> [1] - https://github.com/pubudu538/mesos-artifacts/tree/master/common/svn
>>
>> Thank you!
>>
>> On Wed, Jul 20, 2016 at 10:19 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com <javascript:_e(%7B%7D,'cvml','raviha...@wso2.com');>>
>> wrote:
>>
>>> Hi Pubudu,
>>>
>>> Why are we using wso2/wso2base:latest as the base image here? We have to
>>> run apt-get update and install subversion anyway right?
>>>
>>> IMHO, we need to add artifacts for deploying this on Mesos, Kubernetes
>>> etc. and integrate this with WSO2 DepSync. Shall we work on delivering the
>>> complete package as well?
>>>
>>> Thanks.
>>>
>>> On Mon, Jul 18, 2016 at 12:40 PM, Pubudu Gunatilaka <pubu...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','pubu...@wso2.com');>> wrote:
>>>
>>>> Hi,
>>>>
>>>> At the moment there is no any official docker image for SVN[1]. I have
>>>> created the dockerfile and other relevant artifacts for SVN [2]. This is to
>>>> maintain a separate a docker image for SVN for deployment synchronization.
>>>> For dep sync in container deployments, there is a mail thread with subject
>>>> in [3].
>>>>
>>>> Basically rsync is an option for dep sync. But when it compares to SVN,
>>>> the following are the main advantages.
>>>>
>>>> - Can handle several manager nodes
>>>> - SVN Container can accommodate multiple products
>>>> - We can mount a single volume for SVN server only
>>>>
>>>> Please share your thoughts.
>>>>
>>>> [1] - https://hub.docker.com/
>>>> [2] - https://github.com/wso2/dockerfiles/pull/57
>>>> [3] - [Architecture] Dep sync strategies for Carbon 4 products in
>>>> Kubernetes
>>>>
>>>> Thank you!
>>>> --
>>>> *Pubudu Gunatilaka*
>>>> Committer and PMC Member - Apache Stratos
>>>> Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> mobile : +94774078049 <%2B94772207163>
>>>>
>>>>
>>>
>>>
>>> --
>>> Akila Ravihansa Perera
>>> WSO2 Inc.;  http://wso2.com/
>>>
>>> Blog: http://ravihansa3000.blogspot.com
>>>
>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>

-- 
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

Re: [Dev] [VOTE] Release WSO2 API Manager 2.0.0 RC3

[Akila Ravihansa Perera]

Hi Abimaran,

Shouldn't we include a list of bugs fixed and features added in the release
vote? Ideally this should be a JIRA filter link.

Thanks.

On Thu, Jul 21, 2016 at 12:21 AM, Abimaran Kugathasan <abima...@wso2.com>
wrote:

>
> *WSO2 API Manager 2.0.0-RC3 Released*
>
> This is the 3rd Release Candidate of the WSO2 API Manager 2.0.0
>
> Source & binary distribution files of API Manager 2.0.0-RC3 :
>
>  Runtime :
> https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc3
>  Analytics :
> https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc3
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
> Refer to github readme for guides.
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-]  Broken - do not release (please explain why)
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> <http://stackoverflow.com/users/515034>
> <http://lk.linkedin.com/in/abimaran>
> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
> <https://twitter.com/abimaran>
>
>
> _______
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [Puppet Modules] AWS Membership Scheme Configuration Support

[Akila Ravihansa Perera]

Hi,

1. Mysql connector needs to copy each and every product.  Anyhow, in cloud
>> puppet modules we used to place it in wso2base module.
>>
>> ​Yes, we need to fix this. @Rasanjaya: Would you mind contributing?
>

Puppet file bucket integration and AWS S3 integration are in the road map.
We couldn't look into this due to other priorities.


> ​
>
>
>> 2. A Pupppetmaster host entry gets deleted in /etc/hosts file once we run
>> the puppet in agent nodes. [Added this IP into hiera common.yaml, due to
>> resolve the master's IP]
>>
>> ​@Akila: Any thoughts on this?
>

Yes, this was a known issue. I've fixed it in [1]. This won't affect Docker
scenario since we are adding host mappings only in VM scenario. I've used
"host" Puppet resource type [2] so that it won't be platform dependent.
This can be used with Max, Win etc.



> ​
>
>
>> 3. Each and every time the config file change [Ex: axis2.xml] product
>> gets deleted and start with the fresh configuration.
>>
>
> ​Agree! It should not start from the beginning for a configuration change.
>

Yes, this needs to be fixed. I'll follow up on this as well.



>
>> 4. In clustering, Is there any reason to use the  sub_domain
>> [Ex:sub_domain: worker]? In cloud we are not using this anymore.  This used
>> to identify the manager, worker separation in previous Stratos and now this
>> will treat through the URL and LB [AWS LB or Nginx]. So then we can specify
>> this configuration in default.yaml in the relevant product.  No need to
>> reiterate again and again.
>>
>> A good point! Will remove the sub-domain property from Hiera and template
> files.
>

+1 for removing this from template. But are we sure this property is not
used in any scenario?

[1]
https://github.com/wso2/puppet-modules/commit/25821de9d7fd37b351a305fc8777a33bbe49e13e
[2] https://docs.puppet.com/puppet/latest/reference/types/host.html

-- 
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

Re: [Dev] Adding SVN dockerfiles to wso2/dockerfiles

[Akila Ravihansa Perera]

Hi Pubudu,

Why are we using wso2/wso2base:latest as the base image here? We have to
run apt-get update and install subversion anyway right?

IMHO, we need to add artifacts for deploying this on Mesos, Kubernetes etc.
and integrate this with WSO2 DepSync. Shall we work on delivering the
complete package as well?

Thanks.

On Mon, Jul 18, 2016 at 12:40 PM, Pubudu Gunatilaka <pubu...@wso2.com>
wrote:

> Hi,
>
> At the moment there is no any official docker image for SVN[1]. I have
> created the dockerfile and other relevant artifacts for SVN [2]. This is to
> maintain a separate a docker image for SVN for deployment synchronization.
> For dep sync in container deployments, there is a mail thread with subject
> in [3].
>
> Basically rsync is an option for dep sync. But when it compares to SVN,
> the following are the main advantages.
>
> - Can handle several manager nodes
> - SVN Container can accommodate multiple products
> - We can mount a single volume for SVN server only
>
> Please share your thoughts.
>
> [1] - https://hub.docker.com/
> [2] - https://github.com/wso2/dockerfiles/pull/57
> [3] - [Architecture] Dep sync strategies for Carbon 4 products in
> Kubernetes
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
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

Re: [Dev] [Mesos artifacts] Deploy script is failing to check database service

[Akila Ravihansa Perera]

Hi Imesh,

Sorry for the confusion. In deploy script we are using DCOS CLI to get the
status of the service. We had a Python script earlier to create a TCP
socket to check whether service is active. But that is not a reliable
solution since network might not be reachable from where the deploy script
is being executed and also creating a TCP socket is not equivalent to
creating a HTTP connection and checking the HTTP status code which is
already handled by Mesos. So we offload that work to Mesos and let the
users define any type of health check they think is suitable.

Thanks.

On Wed, Jul 20, 2016 at 4:57 PM, Imesh Gunaratne <im...@wso2.com> wrote:

>
>
> On Wed, Jul 20, 2016 at 1:19 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> mysqladmin client need not be installed on host machine since Mesos will
>> run this command as a "docker run" command which will be executed inside
>> the container. MySQL official image contains mysqladmin tool so this is not
>> a problem.
>>
>
> ​I thought this was regarding the check we need to make before deploying
> the WSO2 server containers to wait until MySQL containers become ready.
> ​
>
> ​Thanks​
>
>
>> Thanks.
>>
>> On Wed, Jul 20, 2016 at 12:46 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>> Hi Akila,
>>>
>>> On Mon, Jul 18, 2016 at 4:58 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
>>>> Hi Imesh,
>>>>
>>>> I've switched to command based health check for MySQL services. It will
>>>> basically run "mysqladmin -u $MYSQL_USER -p$MYSQL_PASSWORD status". This
>>>> will ensure MySQL service is ready to serve SQL requests.
>>>>
>>>
>>> ​Wouldn't this make it mandatory to have mysqladmin client installed in
>>> the host machine where the deployment script is run?
>>>
>>> Thanks​
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> On Mon, Jul 18, 2016 at 9:56 AM, Imesh Gunaratne <im...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 7, 2016 at 10:51 AM, Isuru Haththotuwa <isu...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Yes, myself and Pubudu also faced this issue, lets fix it properly.
>>>>>>
>>>>>> On Wed, Jul 6, 2016 at 10:57 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Akila,
>>>>>>>
>>>>>>> Yes we faced several issues related to this. Apart from what you
>>>>>>> have mentioned, we encountered mysql app name is not getting resolved. 
>>>>>>> This
>>>>>>> could be the delay in updating Mesos DNS. For these issues we looking 
>>>>>>> into
>>>>>>> following options.
>>>>>>>
>>>>>>> *Option 1:*
>>>>>>> Use a sleep before deploying a carbon server. Not the best option.
>>>>>>>
>>>>>>> *Option 2:*
>>>>>>> Depend on the health status results.
>>>>>>>
>>>>>>> Currently, we do use a health check for mysql apps. Using dcos CLI
>>>>>>> we can check the status of the app whether the app is alive or not. But
>>>>>>> this cannot guarantee the DBs are ready to serve requests and Mesos DNS 
>>>>>>> is
>>>>>>> updated.
>>>>>>>
>>>>>>
>>>>>
>>>>>> What if we query the Mesos DNS in addition to port checking to see if
>>>>>> its updated? AFAIR what we are seeing is an 
>>>>>> java.net.UnknownHostException,
>>>>>> related to the DB hostname.
>>>>>>
>>>>>
>>>>> ​May be we can wait for MySQL sockets as we do for Carbon server
>>>>> transports.
>>>>>
>>>>> Thanks​
>>>>>
>>>>> --
>>>>> *Imesh Gunaratne*
>>>>> Software Architect
>>>>> WSO2 Inc: http://wso2.com
>>>>> T: +94 11 214 5345 M: +94 77 374 2057
>>>>> W: https://medium.com/@imesh TW: @imesh
>>>>> lean. enterprise. middleware
>>>>>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Akila Ravihansa Perera
>>>> WSO2 Inc.;  http://wso2.com/
>>>>
>>>> Blog: http://ravihansa3000.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Software Architect
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: https://medium.com/@imesh TW: @imesh
>>> lean. enterprise. middleware
>>>
>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
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

Re: [Dev] [Mesos artifacts] Deploy script is failing to check database service

[Akila Ravihansa Perera]

Hi Imesh,

mysqladmin client need not be installed on host machine since Mesos will
run this command as a "docker run" command which will be executed inside
the container. MySQL official image contains mysqladmin tool so this is not
a problem.

Thanks.

On Wed, Jul 20, 2016 at 12:46 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> Hi Akila,
>
> On Mon, Jul 18, 2016 at 4:58 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> I've switched to command based health check for MySQL services. It will
>> basically run "mysqladmin -u $MYSQL_USER -p$MYSQL_PASSWORD status". This
>> will ensure MySQL service is ready to serve SQL requests.
>>
>
> ​Wouldn't this make it mandatory to have mysqladmin client installed in
> the host machine where the deployment script is run?
>
> Thanks​
>
>
>>
>> Thanks.
>>
>> On Mon, Jul 18, 2016 at 9:56 AM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>>
>>>
>>> On Thu, Jul 7, 2016 at 10:51 AM, Isuru Haththotuwa <isu...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Yes, myself and Pubudu also faced this issue, lets fix it properly.
>>>>
>>>> On Wed, Jul 6, 2016 at 10:57 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Akila,
>>>>>
>>>>> Yes we faced several issues related to this. Apart from what you have
>>>>> mentioned, we encountered mysql app name is not getting resolved. This
>>>>> could be the delay in updating Mesos DNS. For these issues we looking into
>>>>> following options.
>>>>>
>>>>> *Option 1:*
>>>>> Use a sleep before deploying a carbon server. Not the best option.
>>>>>
>>>>> *Option 2:*
>>>>> Depend on the health status results.
>>>>>
>>>>> Currently, we do use a health check for mysql apps. Using dcos CLI we
>>>>> can check the status of the app whether the app is alive or not. But this
>>>>> cannot guarantee the DBs are ready to serve requests and Mesos DNS is
>>>>> updated.
>>>>>
>>>>
>>>
>>>> What if we query the Mesos DNS in addition to port checking to see if
>>>> its updated? AFAIR what we are seeing is an java.net.UnknownHostException,
>>>> related to the DB hostname.
>>>>
>>>
>>> ​May be we can wait for MySQL sockets as we do for Carbon server
>>> transports.
>>>
>>> Thanks​
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Software Architect
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: https://medium.com/@imesh TW: @imesh
>>> lean. enterprise. middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
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

Re: [Dev] [Mesos artifacts] Deploy script is failing to check database service

[Akila Ravihansa Perera]

Hi Imesh,

I've switched to command based health check for MySQL services. It will
basically run "mysqladmin -u $MYSQL_USER -p$MYSQL_PASSWORD status". This
will ensure MySQL service is ready to serve SQL requests.

Thanks.

On Mon, Jul 18, 2016 at 9:56 AM, Imesh Gunaratne <im...@wso2.com> wrote:

>
>
> On Thu, Jul 7, 2016 at 10:51 AM, Isuru Haththotuwa <isu...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Yes, myself and Pubudu also faced this issue, lets fix it properly.
>>
>> On Wed, Jul 6, 2016 at 10:57 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>> wrote:
>>
>>> Hi Akila,
>>>
>>> Yes we faced several issues related to this. Apart from what you have
>>> mentioned, we encountered mysql app name is not getting resolved. This
>>> could be the delay in updating Mesos DNS. For these issues we looking into
>>> following options.
>>>
>>> *Option 1:*
>>> Use a sleep before deploying a carbon server. Not the best option.
>>>
>>> *Option 2:*
>>> Depend on the health status results.
>>>
>>> Currently, we do use a health check for mysql apps. Using dcos CLI we
>>> can check the status of the app whether the app is alive or not. But this
>>> cannot guarantee the DBs are ready to serve requests and Mesos DNS is
>>> updated.
>>>
>>
>
>> What if we query the Mesos DNS in addition to port checking to see if its
>> updated? AFAIR what we are seeing is an java.net.UnknownHostException,
>> related to the DB hostname.
>>
>
> ​May be we can wait for MySQL sockets as we do for Carbon server
> transports.
>
> Thanks​
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [Dockerfiles] Improvements to wso2base image

[Akila Ravihansa Perera]

Hi,

We have also included a feature to enable debug mode for WSO2 servers. This
can be enabled by passing "DEBUG" env variable with the port number to
listen on for debug connections.

You can also pass any system properties to WSO2 servers by adding those to
"STARTUP_ARGS" env variable which will be passed when calling the server
startup script. Setting DEBUG env variable will simply append ' -debug
$DEBUG' to STARTUP_ARGS.

DEBUG property was originally added by GayanG. I modified it to support
setting any system property in Docker run-time.

This is now pushed to DockerHub [1].

[1] https://hub.docker.com/r/wso2/wso2base/tags/

Thanks.

On Mon, Jul 11, 2016 at 11:57 AM, Imesh Gunaratne <im...@wso2.com> wrote:

> Thanks for the update Akila!
>
> On Mon, Jul 11, 2016 at 11:15 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> We have made few improvements in wso2base Dockerfile [1] and init script
>> [2].
>>
>>  - Included 'net-tools' package by default. Commands bundled with this
>> package are widely used when troubleshooting network related issues (eg:
>> netstat, ifconfig, hostname, route).
>>
>>  - Introduced "/mnt/wso2-artifacts" folder to copy any kind of artifact
>> to CARBON_HOME directory (will be copied recursively and relative to folder
>> structure)
>>   This can be used as a mount point if a user wants to copy artifacts at
>> the Docker run-time.
>>
>> We will be deprecating the old artifacts folder: '/mnt/wso2/carbon-home'
>> to avoid confusion with CARBON_HOME symlink.
>>
>>
>> [1] https://github.com/wso2/dockerfiles/blob/master/wso2base/Dockerfile
>> [2]
>> https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh
>>
>> Thanks.
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
>
>


-- 
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

[Dev] [Dockerfiles] Improvements to wso2base image

[Akila Ravihansa Perera]

Hi,

We have made few improvements in wso2base Dockerfile [1] and init script
[2].

 - Included 'net-tools' package by default. Commands bundled with this
package are widely used when troubleshooting network related issues (eg:
netstat, ifconfig, hostname, route).

 - Introduced "/mnt/wso2-artifacts" folder to copy any kind of artifact to
CARBON_HOME directory (will be copied recursively and relative to folder
structure)
  This can be used as a mount point if a user wants to copy artifacts at
the Docker run-time.

We will be deprecating the old artifacts folder: '/mnt/wso2/carbon-home' to
avoid confusion with CARBON_HOME symlink.


[1] https://github.com/wso2/dockerfiles/blob/master/wso2base/Dockerfile
[2]
https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh

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

Re: [Dev] [Mesos artifacts] Deploying wso2das 3.x.x on Mesos

[Akila Ravihansa Perera]

Hi,

I had an offline discussion with Imesh and Isuru regarding this and we came
to a conclusion that best way to use wso2das on Mesos is by using Mesos
Spark framework and use wso2das in client mode and point to Mesos-Spark
masters. This is because Mesos has a built-in mechanism (Spark driver to
connect to Mesos) to schedule jobs as containers in Mesos. This is a more
efficient way to utilize resources than running Spark jobs in a single
container.

PaaS team will look into integrating wso2das with Spark on Mesos and
prepare necessary instructions.

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

[Dev] [Mesos artifacts] Deploy script is failing to check database service

[Akila Ravihansa Perera]

Hi,

When deploying services to Mesos, the deploy script checks whether port is
open in marathon-lb. But this check fails to identify whether MySQL DBs are
up and running. We might have to figure out a way to handle this. Because
of this issue, the product fails to startup since databases are not ready
to serve requests. The product deployment needs to be on hold until all
databases are ready serve requests.

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

Re: [Dev] [Mesos artifacts] Deploying wso2das 3.x.x on Mesos

[Akila Ravihansa Perera]

[Looping Anjana and Isuru]

@Anjana, Niranda: is it possible to plugin a custom member discovery scheme
for Spark? In the current implementation how does a wso2das with embedded
Spark instance discover the other members?
I'm referring to Spark cluster mode deployment here.

Thanks.

On Wed, Jul 6, 2016 at 6:49 AM, Nirmal Fernando <nir...@wso2.com> wrote:

> [Looping Niranda]
>
> On Tue, Jul 5, 2016 at 10:22 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> Deploying wso2das in Mesos is bit tricky due to lack of overlay network
>> support in Mesos OOTB. This is mainly because Spark cluster (when running
>> in Spark cluster mode) is unable to communicate through Docker IP addresses
>> when they are assigned to different host machines in a multi-node Mesos
>> deployment. I checked the config options in [1] and tried setting
>> SPARK_PUBLIC_DNS parameter to Mesos host IP without any success.
>>
>> The main problem is there is no way to instruct Spark members to bind to
>> the local Docker IP and advertise a different IP (Mesos slave host IP) to
>> other members.
>>
>> @Niranda, Nirmal: is this something we can fix from our side? AFAIU, we
>> are using Hazelcast to discover Spark/wso2das members and adding them to
>> Spark context, right?
>>
>> On a side note, there is a Wiki page explaining how Spark should be used
>> with Mesos in [2]. This is available after Spark 1.2.0. In this approach,
>> we treat each Mesos slave as a Spark member and Spark/Mesos driver can
>> directly schedule tasks on Mesos slaves instead of running Spark itself as
>> a container. We should consider this approach in our C5 based efforts. We
>> can leverage Kubernetes in the same way.
>>
>> IMO, we should recommend users to use wso2das in Spark client mode on
>> Mesos due to these complexities.
>>
>
> +1, if we can't solve above from within DAS.
>
>
>> There is a DCOS Mesos framework for Spark [3] which can be used to deploy
>> Spark on Mesos very easily. We can even leverage DCOS Spark framework in
>> our deploy scripts.
>>
>> [1] http://spark.apache.org/docs/latest/spark-standalone.html
>> [2] http://spark.apache.org/docs/latest/running-on-mesos.html
>> [3] https://docs.mesosphere.com/1.7/usage/service-guides/spark/
>>
>> Thanks.
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Team Lead - WSO2 Machine Learner
> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.blogspot.com/
>
>
>


-- 
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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi,

On Tue, Jul 5, 2016 at 11:38 AM, Osura Rathnayake <osura...@gmail.com>
wrote:

> Hi Akila,
>
> Please check the modified code. It now takes the value which is specified
> as localMemberPort in axis2.xml.
>

I still don't see any change to the logic of how member address is
calculated. Can you double check?

Please make sure "target/**" directories are ignored from .gitignore. These
shouldn't be in the repo [1]. You might also need to ignore any IDE
specific files. Have a look at .gitignore in Kubernetes artifacts [2].

I see that you have committed some test cases based on JUnit. Please note
that as a platform we are moving to testng framework so better to use that.
@Imesh, Isuru: Please correct me if I'm wrong.

Shall we get a repo created under wso2-incubator for this?

[1] https://github.com/osuran/azure-membership-scheme/tree/master/target
[2] https://github.com/wso2/kubernetes-artifacts/blob/master/.gitignore

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

[Dev] [Mesos artifacts] Deploying wso2das 3.x.x on Mesos

[Akila Ravihansa Perera]

Hi,

Deploying wso2das in Mesos is bit tricky due to lack of overlay network
support in Mesos OOTB. This is mainly because Spark cluster (when running
in Spark cluster mode) is unable to communicate through Docker IP addresses
when they are assigned to different host machines in a multi-node Mesos
deployment. I checked the config options in [1] and tried setting
SPARK_PUBLIC_DNS parameter to Mesos host IP without any success.

The main problem is there is no way to instruct Spark members to bind to
the local Docker IP and advertise a different IP (Mesos slave host IP) to
other members.

@Niranda, Nirmal: is this something we can fix from our side? AFAIU, we are
using Hazelcast to discover Spark/wso2das members and adding them to Spark
context, right?

On a side note, there is a Wiki page explaining how Spark should be used
with Mesos in [2]. This is available after Spark 1.2.0. In this approach,
we treat each Mesos slave as a Spark member and Spark/Mesos driver can
directly schedule tasks on Mesos slaves instead of running Spark itself as
a container. We should consider this approach in our C5 based efforts. We
can leverage Kubernetes in the same way.

IMO, we should recommend users to use wso2das in Spark client mode on Mesos
due to these complexities. There is a DCOS Mesos framework for Spark [3]
which can be used to deploy Spark on Mesos very easily. We can even
leverage DCOS Spark framework in our deploy scripts.

[1] http://spark.apache.org/docs/latest/spark-standalone.html
[2] http://spark.apache.org/docs/latest/running-on-mesos.html
[3] https://docs.mesosphere.com/1.7/usage/service-guides/spark/

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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi Osura,

As Isuru mentioned you need to be clear about tenantId since it might
conflict with Carbon tenantId. As suggested, please rename it to something
like AZURE_TENANT_ID or something like that.

Regarding localMemberPort in axis2.xml, the value of this parameter should
be same in all nodes by convention therefore no need read localMemberPort
parameter value in each member's axis2.xml. When adding members to
Hazelcast config context you need to take the value of this parameter.
Because we cannot guarantee that it will be 4000 in every deployment. There
are some special cases in which we need to change this. Have a look at [1]
to see how this is handled in Mesos membership scheme.

[1]
https://github.com/wso2/mesos-artifacts/blob/master/common/mesos-membership-scheme/src/main/java/org/wso2/carbon/clustering/mesos/MesosMembershipScheme.java#L247

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi Osura,

I'm still not clear on tenantId. Perhaps you can explain in detail during
the code review meeting. Regarding the last point, yes it should be
localMemberPort. Sorry, it was a typo.

One more thing, I noticed that test cases are empty [1]. Are you still
working on implementing those?

[1]
https://github.com/osuran/azure-membership-scheme/blob/master/src/test/java/org/wso2/carbon/clustering/azure/AppTest.java

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Configure SSO for WSO2 products using WSO2 puppet modules

[Akila Ravihansa Perera]

>
>
>> I have created relevant jiras in [1] and [2].
>>
>> [1] - https://wso2.org/jira/browse/PMODULES-1
>>
>
> ​I do not think we need a JIRA for this task on Puppet Modules side as it
> is not released yet.​
>

I didn't get what you meant by this. We need to track this from Puppet side
because once IS product team fixes it then we need to update the template
from Puppet side.

-- 
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

Re: [Dev] Configure SSO for WSO2 products using WSO2 puppet modules

[Akila Ravihansa Perera]

rvice_url: 
>>>>> *https://wso2esb-default:9443/acs
>>>>> <https://wso2esb-default:9443/acs>*
>>>>> wso2as:
>>>>>   assertion_consumer_service_url: *https://wso2as-default:9443/acs
>>>>> <https://wso2as-default:9443/acs>*
>>>>>   default_assertion_consumer_service_url: 
>>>>> *https://wso2as-default:9443/acs
>>>>> <https://wso2as-default:9443/acs>*
>>>>>
>>>>> This will do the following changes in WSO2 IS side.
>>>>> 1. Add a new service_provider block in sso-idp-config.xml.
>>>>> 2. Create a new file under
>>>>> /repository/conf/identity/service-providers/ directory with the
>>>>> same name of the service provider.
>>>>>
>>>>> The advantage of this is we can use this with docker containers. I
>>>>> have tested this in Mesos. Please share your thoughts.
>>>>>
>>>>> [1] -
>>>>> https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/common.yaml#L169
>>>>> [2] -
>>>>> https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2is/5.1.0/default/default.yaml#L35
>>>>>
>>>>> Thank you!
>>>>> --
>>>>> *Pubudu Gunatilaka*
>>>>> Committer and PMC Member - Apache Stratos
>>>>> Software Engineer
>>>>> WSO2, Inc.: http://wso2.com
>>>>> mobile : +94774078049 <%2B94772207163>
>>>>>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sanjaya Ratnaweera
>>>> Associate Technical Lead; WSO2 Inc; http://www.wso2.com/.
>>>>
>>>> blog: http://www.samudura.org
>>>> homepage: http://www.samudura.net
>>>> twitter: http://twitter.com/sanjayar
>>>> Phone: +94 773037349
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>
>>>
>>>
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>
>>
>> --
>> Sanjaya Ratnaweera
>> Associate Technical Lead; WSO2 Inc; http://www.wso2.com/.
>>
>> blog: http://www.samudura.org
>> homepage: http://www.samudura.net
>> twitter: http://twitter.com/sanjayar
>> Phone: +94 773037349
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi Osura,

Good progress :)

Netflix Feign [1] is a highly customizable and easy to use REST API client
framework. The GitHub page itself contains many samples. We have written
Mesos membership scheme [2] using that which you can use as a reference
guideline. Please refactor your code to use this client. Let me know if you
run into any issues.

I noticed few more issues in the code;
 - No need to define a variable and assign a const [3]. You can directly
use the const.
 - Why do you need to append tenantId to authorization endpoint? Just
asking to clarify why tenantId is needed here.

- You can move common operations to common method. In [4], instead of
checking for empty values and in [5] reading from System.env. Move all that
to getParameterValue method. This will reduce the amount of code you have
to write.

 - You don't have to log and throw [6]. This will only clutter the log file.

 - You don't need a for loop here [7]. Simply use a for-each iterator.

 - Don't put ":" in front of the placeholder [8]

 - Don't put spaces around square brackets [9]

 - You need to separate variables by commas [10]

 - Use proper case for log msg labels [11]. Should be "VM-IP" or simply "IP
Address" is enough. This should contain both IP and local port. Read below
for more info on local port.

* This is very important *
 - Use localMemberHostPort defined in axis2.xml when adding the member IPs
in [12]. This is the port that all WSO2 server instances are listening on
for Hazelcast connections. By default it is 4000 that's why it works now.
But for some reason if someone changes it, then this code will break.

[1] https://github.com/Netflix/feign
[2]
https://github.com/wso2/mesos-artifacts/tree/master/common/mesos-membership-scheme
[3]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L101
[4]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L113
[5]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L110
[6]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L182
[7]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L200
[8]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L263
[9]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L282
[10]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L171
[11]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L177
[12]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L176

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Getting error when starting WSO2 IS 5.1.0 Key Manager in Mesos DC/OS

[Akila Ravihansa Perera]

gt;>>> [2].
>>>> http://product-dist.wso2.com/downloads/api-manager/1.10.0/identity-server/wso2is-5.1.0.zip
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Thanuja Uruththirakodeeswaran
>>>> Software Engineer
>>>> WSO2 Inc.;http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 774363167
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Technical Lead - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>
>> Regards,
>> Nira
>>
>> --
>>
>>
>> *Niranjan Karunanandham*
>> Associate Technical Lead - WSO2 Inc.
>> WSO2 Inc.: http://www.wso2.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> Lean . Enterprise . Middleware
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi,


>
>> Regarding tag names, it was done on purpose do multiple Puppet module
>> releases for a specific WSO2 product version. I know it's ugly, but would
>> like to hear others' thoughts/suggestions.
>>
>
> ​I'm sorry I do not get this.​
>
> ​Can you please explain this in more detail?
>

I take back what I said :) Let me put it this way; we used Puppet to
provision the images which got pushed to DockerHub. We had named the Puppet
modules as wso2-: so that
multiple Puppet module releases were possible for a one product version.
That's why (I think) these images were named the same way Puppet modules
were which was a mistake on our part. Thanks Ramon for pointing this out.

Also regarding platform specific Docker images; eg: "mesos", "kubernetes"
etc. there is a separate thread to discuss it. Refer to mail thread "Naming
convention for WSO2 docker images based on the platform". In summary,
current approach is to append the platform name to the Docker image name
itself.
@Ramon: Do you have any objections against this? You are most welcome to
share your thoughts on that thread.

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

[Dev] Mesos DNS support for Mesos membership scheme

[Akila Ravihansa Perera]

Hi,

Currently Mesos membership scheme relies on Marathon REST API to discover
the members in a cluster. There can be situations where access to Marathon
REST API could be restricted and access cannot be granted for Carbon
products due to security concerns.

However, we can still discover members in the cluster by using Mesos DNS
REST API [1]. I've implemented this functionality in [2]. We can set the
DNS endpoint via MESOS_DNS_ENDPOINT parameter in axis2.xml.
We can change the member discovery scheme by defining
the MESOS_MEMBER_DISCOVERY_SCHEME parameter in axis2.xml. The default will
be 'Marathon' (via Marathon REST API). It is important to understand that
Mesos DNS will periodically query the master node to get a list of members,
therefore it is possible that there will be a delay to reflect the latest
state. I've introduced a DNS update timeout (DNS_UPDATE_TIMEOUT which
defaults to 10s), period of time to keep retrying if the service is not
found.

Note that if there are shared Marathon applications when creating a single
Hazelcast cluster you need to include them in MARATHON_APPLICATIONS
parameter as comma separated values. For eg: WSO2 ESB worker/manager setup
wso2esb manager should not have any value for MARATHON_APPLICATIONS since
it should be started first, before the worker. Members in the same
application (wso2esb-manager in this case) will be added by default

wso2esb worker should have "wso2esb-manager" as MARATHON_APPLICATIONS since
it will be started after the manager.

[1] https://mesosphere.github.io/mesos-dns/docs/http.html
[2]
https://github.com/wso2/mesos-artifacts/tree/master/common/mesos-membership-scheme

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

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi Ramon,

Thanks for sharing this but we will not be able make these official due to
OracleJDK license issues. OpenJDK will be fully supported in Carbon 5 based
products but that will take some time.

Regarding tag names, it was done on purpose do multiple Puppet module
releases for a specific WSO2 product version. I know it's ugly, but would
like to hear others' thoughts/suggestions.

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi,

I've merged the PR [1] which introduces wso2base image. This base image
will include packages that were previously installed from Puppet (zip and
unzip), and those are removed from Puppet/Hiera side. With that we should
be able to build WSO2 Docker images in offline mode.

wso2base image is pushed to DockerHub [2] as well. You don't need to build
it locally.

[1] https://github.com/wso2/dockerfiles/pull/46
[2] https://hub.docker.com/r/wso2/wso2base/

Thanks.

On Thu, Jun 23, 2016 at 3:06 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> Hi Isuru/Akila,
>
> On Tue, Jun 21, 2016 at 3:19 PM, Isuru Haththotuwa <isu...@wso2.com>
> wrote:
>
> To summarize:
>
>- Publish a wso2 product specific docker image to a local docker
>repository (we can even push to dockerhub, without the JDK distribution and
>ask the users to provide the JDK when spinning up a container from the
>image).
>
> A good suggestion, since we currently track product downloads for
> analytics we might need to find a way to do the same with Docker if we were
> to publicly share WSO2 Docker images. Otherwise using a local registry with
> a base/product image would do.
>
>- Guide the users/developers to create their own Dockerfile extending
>from the original wso2 product Docker image.
>
> We might need to solve 1, to do this.
>
> On Thu, Jun 23, 2016 at 9:42 AM, Isuru Haththotuwa <isu...@wso2.com>
> wrote:
>
>>
>> On Tue, Jun 21, 2016 at 6:54 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>>
>>> I'm not against having a base image for the WSO2 Docker images. But,
>> IMHO the advantages should be significant for doing so. AFAIU there is no
>> significant advantage of doing so currently. But, this is my take only.
>> Therefore lets get the input from the community on this matter.
>>
>> @Imesh: WDYT?
>>
>> ​Currently almost all of us use a base image locally to reduce the
> internet bandwidth usage due to executing docker builds from scratch.
> Therefore I think it would be better to push that to the remote repository.
>
> As Akila has mentioned the only downside of this is the image size being
> increased by around 100 MB. ​When creating Docker images for production
> deployment those optimizations can be taken into account.
>
> Thanks
>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> Lean . Enterprise . Middleware
>
>


-- 
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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi Osura,

I still see some issues in the code.

1. Make sure to use consts when appropriate [1]
2. Where do you use tenantId [2] ?
3. Use the actual parameter key in the error message [3] instead of hard
coding it
4. You need to adhere to max line len of 120 chars. I see this standard
being violated in couple of places [4]. Use IDE formatting tool to fix this
5. Do not keep empty spaces [5]. This is bad code styling

@Imesh: Osura has used Apache HTTP client to send HTTP requests [6]. Shall
we make Netflix Feign the standard for this?

[1]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L117
[2]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L107
[3]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L148
[4]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L181
[5]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L94
[6]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/org/wso2/carbon/clustering/azure/AzureMembershipScheme.java#L234

Thanks.

On Fri, Jun 24, 2016 at 11:05 AM, Imesh Gunaratne <im...@wso2.com> wrote:

>
>
> On Fri, Jun 24, 2016 at 11:00 AM, <osura...@gmail.com> wrote:
>
>> Hi Imesh,
>>
>> Yes I completed the evaluation.
>>
> ​Great! Thanks!​
>
>> Thanks,
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>>
>>
>> On Fri, Jun 24, 2016 at 10:08 AM +0530, "Imesh Gunaratne" <im...@wso2.com
>> > wrote:
>>
>> Hi Osura,
>>>
>>> Were you able to submit the midterm evaluation? Might be better to do it
>>> soon.
>>>
>>> Thanks
>>> ​Imesh​
>>>
>>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> Lean . Enterprise . Middleware
>
>


-- 
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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

Hi Osura,

The code base still needs to be cleaned up.

1. Unnecessary class in [1]
2. Package structure should be refactored from *com.osura.membershipscheme*
to *org.wso2.carbon.clustering.azure*
3. Put proper JavaDoc comments for classes and methods. [2]
4. Do not keep commented code [3]
5. Use String.format when logging parameters [4]
6. Do not print the stack trace to console [5]
7. Thread pool should be initialized separately as a one time task [6]
8. Keep default values as separate consts and use them if no value is
specified [7]
9. Put the WSO2 license header in every file
10. Write unit tests to verify the functionality
11. validateAuthority flag should be configurable [8]

[1]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/App.java
[2]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/AzureMembershipScheme.java#L44
[3]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/AzureMembershipScheme.java#L67
[4]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/AzureMembershipScheme.java#L293
[5]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/authentication/Authentication.java#L38
[6]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/authentication/Authentication.java#L25
[7]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/Constants.java#L13
[8]
https://github.com/osuran/azure-membership-scheme/blob/master/src/main/java/com/osura/membershipscheme/azure/authentication/Authentication.java#L27

Please make sure you complete the above tasks before arranging a code
review.

Thanks.

On Thu, Jun 23, 2016 at 12:15 PM, Osura Rathnayake 
wrote:

> Hi Mentors,
>
> Please arrange a hangout for the code review of membership scheme at any
> time which is convenient for you.
>
> thanks,
>
> On Wed, Jun 22, 2016 at 3:21 PM, Osura Rathnayake 
> wrote:
>
>> Hi Mentors,
>>
>> I have handled the exceptions and pushed the changes to my repository
>> [1]. Please have a look
>>
>>
>>
>> [1] https://github.com/osuran/azure-membership-scheme
>>
>> thanks,
>>
>> On Wed, Jun 22, 2016 at 11:42 AM, Osura Rathnayake 
>> wrote:
>>
>>> Hi Isuru,
>>>
>>> Thank you very much for the feedback.
>>> I updated the snapshot dependency with a released version. Also I made
>>> it use Jackson to parse the API responses using bean classes. And I
>>> properly formatted the code as well. Exceptions handling is still on the
>>> way.
>>> Sure will have a code review this week.
>>>
>>>
>>> On Tue, Jun 21, 2016 at 10:18 AM, Isuru Haththotuwa 
>>> wrote:
>>>
 Hi Osura,

 I went through the code at [1] briefly. Some general comments:

- The code is not properly formatted
- The code has a SNAPSHOT dependency for org.wso2.carbon.utils. If
you do not have a specific reason to do so, its better to use a released
version.
- To parse the responses from the rest API, you are directly
manipulating JSON objects. Have a look at the Kubernetes Membership 
 Scheme.
Its using Jackson to parse the API responses using bean classes. This 
 would
be much easier than directly interacting with JSON structures. Or else, 
 you
can use Netflix Feign as a REST API client [2], in which the amount of 
 code
you have to write is very less.
- System.exit(1) is used in few places to handle error scenarios,
which is wrong. Please use a proper Exception for the purpose

 Noted that you have updated the README file, which is great. Lets have
 a code review this week to go through the functional aspects at a more fine
 grained level.

 [1]. https://github.com/osuran/azure-membership-scheme.git

 [2]. https://github.com/Netflix/feign

 On Thu, Jun 16, 2016 at 11:23 AM, Osura Rathnayake 
 wrote:

> Hi Isuru,
>
> That's great, will do the demo at 3 o'clock in the evening today.
> thanks
>
> On Thu, Jun 16, 2016 at 11:21 AM, Isuru Haththotuwa 
> wrote:
>
>>
>>
>> On Thu, Jun 16, 2016 at 11:10 AM, Osura Rathnayake <
>> osura...@gmail.com> wrote:
>>
>>> Hi Mentors,
>>>
>>> Thank you for the update.
>>> Yes I can demonstrate it anytime today.
>>>
>> Great! Shall we have a hangout at 3.00 PM? The main purpose would be
>> to demonstrate the membership scheme functionality with a carbon cluster
>> deployed in Azure.
>>
>>>
>>>
>>> thanks
>>>
>>> On Thu, Jun 16, 2016 at 10:11 AM, Isuru Haththotuwa 

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi Isuru,

One drawback of not having a wso2base is that in a restricted environment
where Internet connectivity is not available, a private build server will
not be able to build the images using Puppet provisioning if there are any
additional packages to be installed. But if there was a wso2base image,
those packages could have been installed to that and manually loaded into
the build server as a one time task.

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi Isuru,

+1 for the suggested approach. I think wso2base image will only complement
the model that you have described. We can definitely provide guidelines to
users so that they can extend from our product specific images (excluding
Oracle JDK).

If we have the right layered model, i.e.; wso2base -> wso2product ->
wso2product-customized
then we can cut down the network traffic when push/pull'ing images to/from
Docker registries or even locally save/load'ing images. This is because
Docker will pull only the changed top level layer since bottom layers are
do not change for a specific Dockerfiles release. Since wso2base is common
across all products, this will cut down push/pull time in a multi-product
deployment.

wdyt?

Thanks.

On Tue, Jun 21, 2016 at 3:19 PM, Isuru Haththotuwa <isu...@wso2.com> wrote:

> Hi Akila,
>
> If we use a base image, true that we can avoid the time taken to run
> apt-get update and software installation. But still the users will have to
> run the provisioning again and again when doing development/testing. The
> model I suggest is a way to eliminate apt-get update and also the
> provisioning over and over again.
>
> To summarize:
>
>- Publish a wso2 product specific docker image to a local docker
>repository (we can even push to dockerhub, without the JDK distribution and
>ask the users to provide the JDK when spinning up a container from the
>image).
>- Guide the users/developers to create their own Dockerfile extending
>from the original wso2 product Docker image.
>- Use the extension provided to copy artifacts/configurations to the
>container [1]. At development time, ideally the developer would only need
>to modify the configurations/copy artifacts to the carbon server.
>- After the development phase, collect all the changes and apply them
>to the provisioning method (puppet, etc.) that is used, and build the final
>production ready Docker image.
>
> I'm +1 to push a Docker image with a configured product to Dockerhub,
> excluding the JDK and ask the user to provide a JDK at runtime/creating a
> new Dockerfile extending from the original product Dockerfile.
>
> [1].
> https://docs.wso2.com/display/DF110/Running+WSO2+Docker+Images#RunningWSO2DockerImages-Copyingartifactsfromhostmachinetothecontainer
>
> On Mon, Jun 20, 2016 at 12:37 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Isuru,
>>
>> Do you have any specific concerns about using a wso2base image? On
>> average there is a spike of 100MB when using a wso2base image, but that's a
>> small price to pay when considering benefits users would gain out of this.
>> Note that users can use "default" provisioning method to package any
>> jars/configs to the image. The main problem here is the time taken to run
>> apt-get update and package installation. Especially having to download
>> files over I'net every time a Docker image is built which I think is
>> unnecessary. wdyt?
>>
>> Thanks.
>>
>> On Wed, Jun 1, 2016 at 10:31 PM, Isuru Haththotuwa <isu...@wso2.com>
>> wrote:
>>
>>> Hi Akila and Imesh,
>>>
>>> Without creating a base image, if we package everything in a product
>>> specific image, host it in a local registry, and provide instructions to
>>> create a local Dockerfile extending from that image, the time taken to
>>> build the local image would be lesser. This will speedup the
>>> development/testing procedure even more. The developers can package any
>>> apps/jars/configs via the local Dockerfile (using volume mounts, etc.), for
>>> testing. I have seen this pattern used in some Docker images, for an
>>> example in the haproxy Docker image [1].
>>>
>>> One downside is, as you mentioned, we cannot push the image to Dockerhub
>>> with Oracle JDK distribution included. Maybe we can create the product
>>> Docker image with the relevant utilities (wget, zip, unzip, etc.) + the
>>> product distribution, and push it to Docker hub. Then provide an option to
>>> package the JDK via a local Dockerfile extending from the product
>>> Dockerfile.
>>>
>>> WDYT?
>>>
>>> [1]. https://hub.docker.com/_/haproxy/
>>>
>>> On Mon, May 30, 2016 at 12:48 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Currently we don't have a base image for WSO2 Docker images due to
>>>> image size issues we had with it. But later we found out that this was
>>>> mainly due to multiple RUN commands, which caused Docker to add unnecessary
>

[Dev] [Mesos] Let's use Marathon CLI for deploying artifacts

[Akila Ravihansa Perera]

Hi,

Shall we do $subject? Marathon CLI is available for Windows, OS X, Linux
[1]. It supports operations that we need provided via REST API. Main
advantage is it handles authentication if the REST API is secured. Also it
simplifies the bash scripts that we need to develop to deploy services.


[1] https://docs.mesosphere.com/1.7/usage/cli/install/
[2] https://docs.mesosphere.com/1.7/usage/cli/command-reference/

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

Re: [Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi Isuru,

Do you have any specific concerns about using a wso2base image? On average
there is a spike of 100MB when using a wso2base image, but that's a small
price to pay when considering benefits users would gain out of this. Note
that users can use "default" provisioning method to package any
jars/configs to the image. The main problem here is the time taken to run
apt-get update and package installation. Especially having to download
files over I'net every time a Docker image is built which I think is
unnecessary. wdyt?

Thanks.

On Wed, Jun 1, 2016 at 10:31 PM, Isuru Haththotuwa <isu...@wso2.com> wrote:

> Hi Akila and Imesh,
>
> Without creating a base image, if we package everything in a product
> specific image, host it in a local registry, and provide instructions to
> create a local Dockerfile extending from that image, the time taken to
> build the local image would be lesser. This will speedup the
> development/testing procedure even more. The developers can package any
> apps/jars/configs via the local Dockerfile (using volume mounts, etc.), for
> testing. I have seen this pattern used in some Docker images, for an
> example in the haproxy Docker image [1].
>
> One downside is, as you mentioned, we cannot push the image to Dockerhub
> with Oracle JDK distribution included. Maybe we can create the product
> Docker image with the relevant utilities (wget, zip, unzip, etc.) + the
> product distribution, and push it to Docker hub. Then provide an option to
> package the JDK via a local Dockerfile extending from the product
> Dockerfile.
>
> WDYT?
>
> [1]. https://hub.docker.com/_/haproxy/
>
> On Mon, May 30, 2016 at 12:48 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> Currently we don't have a base image for WSO2 Docker images due to image
>> size issues we had with it. But later we found out that this was mainly due
>> to multiple RUN commands, which caused Docker to add unnecessary layers.
>>
>> I think we should bring back the base image for couple of reasons;
>>
>> 1. wso2base image with minimum packages installed (wget, puppet etc) will
>> eliminate the need for having to run apt-get commands (which are very
>> expensive, time-wise) each and every time
>>
>> 2. wso2base image can be hosted publicly (without Oracle JDK of course)
>> so that users don't have to build wso2base but rather pull it from
>> DockerHub.
>>
>> 3. wso2base image provides a Docker layer which reduces the amount of
>> traffic carried when pulling images from a Docker registry over a long
>> period of time. This is because base image is very unlikely to be changed,
>> but product images can change very rapidly (due to artifacts or
>> configuration change, product version etc.). It is unnecessary to carry the
>> information in the lower level layers each time a product image is changed.
>>
>> If you must use a single image, I found this cool Docker tool written in
>> Python which can be used to squash Docker layers called docker-squash [1].
>> Following is a comparison of Docker images built with/without wso2base and
>> squashed images;
>>
>> [image: Inline image 3]
>>
>> In summary;
>> wso2am-1.10.0 with base image: 1.079GB
>> wso2am-1.10.0 with base image and *squashed*: 948MB
>> wso2am-1.10.0 *without* base image: 969MB
>>
>> wso2esb-4.9.0 with base image: 794MB
>> wso2esb-4.9.0 with base image and *squashed*: 664MB
>> wso2esb-4.9.0 *without* base image: 685MB
>>
>> In conclusion, introducing a base image with minimum packages has a image
>> size overhead of around 100+MB, but having individual images without a
>> hierarchy can cause a significant amount of unnecessary information being
>> transferred over the network when pull/push'ing to/from a registry.
>>
>> I've created a PR for this feature at [2]. Also used
>> "--no-install-recommends" option to apt-get when installing packages to
>> prevent unnecessary packages being installed. Please share your thoughts.
>>
>> [1] https://github.com/goldmann/docker-squash
>> [2] https://github.com/wso2/dockerfiles/pull/46/files
>>
>> 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
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>


-- 
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

Re: [Dev] [GSOC 16] Initial Project Progress

[Akila Ravihansa Perera]

t;>>>
>>>>>>>>>>>> Sorry for the delayed response.
>>>>>>>>>>>>
>>>>>>>>>>>> Shall we have a hangout at 11 AM on 20th May (Friday)?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 17, 2016 at 9:09 PM, Osura Rathnayake <
>>>>>>>>>>>> osura...@gmail.com
>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','osura...@gmail.com');>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Imesh,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Shall we have a hangout on Thursday or so?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, May 12, 2016 at 8:26 PM, Imesh Gunaratne <
>>>>>>>>>>>> im...@wso2.com <javascript:_e(%7B%7D,'cvml','im...@wso2.com');>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Osura,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, May 12, 2016 at 8:09 PM, Osura Rathnayake <
>>>>>>>>>>>> osura...@gmail.com
>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','osura...@gmail.com');>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I created a github repository so that all the work related to
>>>>>>>>>>>> this project can be accumulated with ease.
>>>>>>>>>>>>
>>>>>>>>>>>> here is the link
>>>>>>>>>>>> https://github.com/osuran/azure-membership-scheme.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Great! Will you be able to arrange a Hangout and demonstrate
>>>>>>>>>>>> what you did so far?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, May 12, 2016 at 8:09 PM, Osura Rathnayake <
>>>>>>>>>>>> osura...@gmail.com
>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','osura...@gmail.com');>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I created a github repository so that all the work related to
>>>>>>>>>>>> this project can be accumulated with ease.
>>>>>>>>>>>>
>>>>>>>>>>>> here is the link
>>>>>>>>>>>> https://github.com/osuran/azure-membership-scheme.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 11, 2016 at 11:22 AM, Osura Rathnayake <
>>>>>>>>>>>> osura...@gmail.com
>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','osura...@gmail.com');>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>
>>

[Dev] WSO2 Docker images layered composition

[Akila Ravihansa Perera]

Hi,

Currently we don't have a base image for WSO2 Docker images due to image
size issues we had with it. But later we found out that this was mainly due
to multiple RUN commands, which caused Docker to add unnecessary layers.

I think we should bring back the base image for couple of reasons;

1. wso2base image with minimum packages installed (wget, puppet etc) will
eliminate the need for having to run apt-get commands (which are very
expensive, time-wise) each and every time

2. wso2base image can be hosted publicly (without Oracle JDK of course) so
that users don't have to build wso2base but rather pull it from DockerHub.

3. wso2base image provides a Docker layer which reduces the amount of
traffic carried when pulling images from a Docker registry over a long
period of time. This is because base image is very unlikely to be changed,
but product images can change very rapidly (due to artifacts or
configuration change, product version etc.). It is unnecessary to carry the
information in the lower level layers each time a product image is changed.

If you must use a single image, I found this cool Docker tool written in
Python which can be used to squash Docker layers called docker-squash [1].
Following is a comparison of Docker images built with/without wso2base and
squashed images;

[image: Inline image 3]

In summary;
wso2am-1.10.0 with base image: 1.079GB
wso2am-1.10.0 with base image and *squashed*: 948MB
wso2am-1.10.0 *without* base image: 969MB

wso2esb-4.9.0 with base image: 794MB
wso2esb-4.9.0 with base image and *squashed*: 664MB
wso2esb-4.9.0 *without* base image: 685MB

In conclusion, introducing a base image with minimum packages has a image
size overhead of around 100+MB, but having individual images without a
hierarchy can cause a significant amount of unnecessary information being
transferred over the network when pull/push'ing to/from a registry.

I've created a PR for this feature at [2]. Also used
"--no-install-recommends" option to apt-get when installing packages to
prevent unnecessary packages being installed. Please share your thoughts.

[1] https://github.com/goldmann/docker-squash
[2] https://github.com/wso2/dockerfiles/pull/46/files

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

Re: [Dev] Missing required capability in osgi component

[Akila Ravihansa Perera]

What I'm suggesting is, instead of;





*/** * @scr.component name="org.wso2.carbon.cloud.das.datapurge.tool"
* @scr.reference name="analytics.component"
interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI" *
cardinality="1..1" policy="dynamic" bind="setAnalyticsDataAPI"
unbind="unsetAnalyticsDataAPI" */*

try following;



*/** * @scr.component name="org.wso2.carbon.cloud.das.datapurge.tool"
* @scr.reference name="analytics.component"
** * interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI"
** * cardinality="1..1" policy="dynamic" bind="setAnalyticsDataAPI"
unbind="unsetAnalyticsDataAPI"** */*

The interface's fully qualified name should be in one line.

On Fri, May 27, 2016 at 6:01 PM, Fathima Dilhasha <dilha...@wso2.com> wrote:

> Hi Akila,
>
> Do you suggest that the @scr.reference needs to be specified in one line
> as follows?
>
>
>
>
> ** @scr.reference name="analytics.component" 
> interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI" cardinality="1..1" 
> * policy="dynamic" bind="setAnalyticsDataAPI" unbind="unsetAnalyticsDataAPI"*
>
> @scr.reference interface is not specified in two lines though.
>
> Thanks.
>
>
>
> On Fri, May 27, 2016 at 5:05 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Fathima,
>>
>> The problem is with your service definition;
>>
>>
>>
>>
>>
>> */** * @scr.component name="org.wso2.carbon.cloud.das.datapurge.tool" * 
>> @scr.reference name="analytics.component" 
>> interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI" * 
>> cardinality="1..1" policy="dynamic" bind="setAnalyticsDataAPI" 
>> unbind="unsetAnalyticsDataAPI" */*
>>
>> Notice that @scr.reference interface is split into two lines? This is the
>> root cause. Happened to me once ;)
>>
>> Thanks.
>>
>> On Fri, May 27, 2016 at 1:45 PM, Fathima Dilhasha <dilha...@wso2.com>
>> wrote:
>>
>>> Please find attached pom.xml.
>>>
>>> On Fri, May 27, 2016 at 1:02 PM, Sameera Jayasoma <same...@wso2.com>
>>> wrote:
>>>
>>>> Can you attach the Pom.xml ?
>>>>
>>>>
>>>> On Friday, May 27, 2016, Fathima Dilhasha <dilha...@wso2.com> wrote:
>>>>
>>>>> The service is available and I can actually use it without any
>>>>> problem. I'm calling some methods on it and they are working fine.
>>>>> On 27 May 2016 12:17, "Sameera Jayasoma" <same...@wso2.com> wrote:
>>>>>
>>>>>> Looks like this service is not available in your OSGi environment.
>>>>>>
>>>>>> *org.wso2.carbon.analytics.api.AnalyticsDataAPI*
>>>>>>
>>>>>> Can you double check on this?
>>>>>>
>>>>>> On Fri, May 27, 2016 at 12:08 PM, Anjana Fernando <anj...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Sameera/Niranjan,
>>>>>>>
>>>>>>> You guys have any idea on to why this is happening? .. here, even
>>>>>>> though the OSGi is available and accessible to that bundle, it is still
>>>>>>> giving that message.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Anjana.
>>>>>>>
>>>>>>> On Fri, May 27, 2016 at 10:15 AM, Fathima Dilhasha <
>>>>>>> dilha...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to build an osgi component which uses "
>>>>>>>> *org.wso2.carbon.analytics.api.AnalyticsDataAPI*". When I add the
>>>>>>>> bundle to carbon server, the bundle is working as expected. But in the 
>>>>>>>> osgi
>>>>>>>> console when I diagnose the bundle I get the following.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Direct constraints which are unresolved:Missing required
>>>>>>>> capability Require-Capability: osgi.service;
>>>>>>>> filter="(objectClass=org.wso2.carbon.analytics.api.AnalyticsDataAPI)"*
&g

Re: [Dev] Missing required capability in osgi component

[Akila Ravihansa Perera]

Hi Fathima,

The problem is with your service definition;





*/** * @scr.component name="org.wso2.carbon.cloud.das.datapurge.tool"
* @scr.reference name="analytics.component"
interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI" *
cardinality="1..1" policy="dynamic" bind="setAnalyticsDataAPI"
unbind="unsetAnalyticsDataAPI" */*

Notice that @scr.reference interface is split into two lines? This is the
root cause. Happened to me once ;)

Thanks.

On Fri, May 27, 2016 at 1:45 PM, Fathima Dilhasha <dilha...@wso2.com> wrote:

> Please find attached pom.xml.
>
> On Fri, May 27, 2016 at 1:02 PM, Sameera Jayasoma <same...@wso2.com>
> wrote:
>
>> Can you attach the Pom.xml ?
>>
>>
>> On Friday, May 27, 2016, Fathima Dilhasha <dilha...@wso2.com> wrote:
>>
>>> The service is available and I can actually use it without any problem.
>>> I'm calling some methods on it and they are working fine.
>>> On 27 May 2016 12:17, "Sameera Jayasoma" <same...@wso2.com> wrote:
>>>
>>>> Looks like this service is not available in your OSGi environment.
>>>>
>>>> *org.wso2.carbon.analytics.api.AnalyticsDataAPI*
>>>>
>>>> Can you double check on this?
>>>>
>>>> On Fri, May 27, 2016 at 12:08 PM, Anjana Fernando <anj...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Sameera/Niranjan,
>>>>>
>>>>> You guys have any idea on to why this is happening? .. here, even
>>>>> though the OSGi is available and accessible to that bundle, it is still
>>>>> giving that message.
>>>>>
>>>>> Cheers,
>>>>> Anjana.
>>>>>
>>>>> On Fri, May 27, 2016 at 10:15 AM, Fathima Dilhasha <dilha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to build an osgi component which uses "
>>>>>> *org.wso2.carbon.analytics.api.AnalyticsDataAPI*". When I add the
>>>>>> bundle to carbon server, the bundle is working as expected. But in the 
>>>>>> osgi
>>>>>> console when I diagnose the bundle I get the following.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Direct constraints which are unresolved:Missing required
>>>>>> capability Require-Capability: osgi.service;
>>>>>> filter="(objectClass=org.wso2.carbon.analytics.api.AnalyticsDataAPI)"*
>>>>>> Following are the imported packages in the written osgi component.
>>>>>>
>>>>>> 
>>>>>>
>>>>>> org.apache.commons.logging.*; version="${commons.logging.version}",
>>>>>> org.osgi.service.component; 
>>>>>> version="${imp.pkg.version.osgi.service.component}",
>>>>>> org.osgi.framework; version="${imp.pkg.version.osgi.framework}",
>>>>>> org.wso2.carbon.core; version="${wso2das.version}",
>>>>>> org.wso2.carbon.analytics.api.*; 
>>>>>> version=${wso2analytics.api.version},
>>>>>> org.wso2.carbon.analytics.datasource.commons.exception.*; 
>>>>>> resolution:=optional
>>>>>> 
>>>>>>
>>>>>>
>>>>>> Following are the scr tags specified in the component.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> */** * @scr.component name="org.wso2.carbon.cloud.das.datapurge.tool" * 
>>>>>> @scr.reference name="analytics.component" 
>>>>>> interface="org.wso2.carbon.analytics.api.AnalyticsDataAPI" * 
>>>>>> cardinality="1..1" policy="dynamic" bind="setAnalyticsDataAPI" 
>>>>>> unbind="unsetAnalyticsDataAPI" */*
>>>>>>
>>>>>> I highly appreciate any help on understandng this issue.
>>>>>>
>>>>>> Thanks
>>>>>> Regards,
>>>>>> Dilhasha
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Fathima Dilhasha
>>>>>> *Software Engineer*
>>>>>> Mobile : +94 (0) 77

Re: [Dev] Puppet modules are not compatible with puppet 4

[Akila Ravihansa Perera]

Hi Manuranga,

This is not exactly a Puppet issue, rather Vagrant provisioning we have
used is not compatible with Puppet 4. So the $subject is kind of misleading
:)
We will look into this issue and fix in the next release, if it needs
fixing. Please create a JIRA for this.

Regarding Puppet 4 compatibility, we haven't tested yet. But looking at the
deprecation list [1], I don't see any blockers. Please do raise if you
notice any issues with Puppet 4.

[1]
https://docs.puppet.com/puppet/3.8/reference/deprecated_language.html#in-puppet-40-1

Thanks.

On Thu, May 26, 2016 at 9:39 PM, Manuranga Perera <m...@wso2.com> wrote:

> We are using non-environment puppet mode this is not compatible with
> puppet 4 [1]
>
> If manifests_path and manifest_file are specified without environments,
>> the old non-environment mode will be used (which will fail on Puppet 4+).
>> [2]
>
>
> Are we planing to update to be compatible with puppet 4?
>
> [1] https://github.com/mitchellh/vagrant/issues/5615
> [2] https://www.vagrantup.com/docs/provisioning/puppet_apply.html
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [DEV][Vote] Release WSO2 Puppet Modules 2.0.0

[Akila Ravihansa Perera]

;Improve Puppet Vagrant setup to use PUPPET_HOME environment variable
>>>-
>>>
>>>Included sample config.yaml files in the Puppet Vagrant setup to
>>>quickly test standalone and distributed deployments
>>>-
>>>
>>>Fixed Java System Prefs location issue
>>>-
>>>
>>>Included YAML Style Guide for Hiera data files
>>>
>>>
>>>
>>> This release is based on the following tag:
>>>
>>> https://github.com/wso2/puppet-modules/releases/tag/v2.0.0-rc1
>>>
>>> Release verification guide can be found at:
>>>
>>>
>>> https://docs.wso2.com/display/PM200/Setting+up+the+Development+Environment
>>>
>>> Source and distribution packages can be downloaded at:
>>>
>>> https://github.com/wso2/puppet-modules/releases/tag/v2.0.0-rc1
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.io TW: @imesh
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanuja Uruththirakodeeswaran
> Software Engineer
> WSO2 Inc.;http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 774363167
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

You do not have to add config data for each hierarchy. If you want to use
without any platform configuration then you can set the "platform" facter
variable to "default".

On Tue, May 10, 2016 at 9:54 AM, Lakmal Warusawithana <lak...@wso2.com>
wrote:

> Say platform k8s , we need to have vm_type right? I want to use vm_type
> docker , but without any platform configuration. How can I do that?
>
> On Tue, May 10, 2016 at 9:51 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Lakmal,
>>
>> Hierarchy will be the same (hiera.yaml). You need to set docker-compose
>> specific configuration in "vm_type/docker-compose.yaml" file. This is for
>> when building the image. Puppet cannot handle run time configuration in
>> container scenario. If there is no platform (Mesos, K8s etc.) involved then
>> no need to create platform specific yaml files.
>>
>> I think hiera.yaml should be abstract and flexible enough that a user
>> should be able to deploy WSO2 products/services on any platform or
>> container/VM type without changing it. Of course there can be custom
>> requirements. But this should suffice for most cases.
>>
>> Thanks.
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana <lak...@wso2.com>
>> wrote:
>>
>>> Say I want to use in docker-compose (with pure docker). What hiera files
>>> (config) I have to use?
>>>
>>> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis <chami...@wso2.com>
>>> wrote:
>>>
>>>> I agree. Let's keep vm_type for simplicity.
>>>>
>>>>
>>>> Regards,
>>>> Chamila de Alwis
>>>> Committer and PMC Member - Apache Stratos
>>>> Software Engineer | WSO2 | +94772207163
>>>> Blog: code.chamiladealwis.com
>>>>
>>>>
>>>>
>>>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>>>> raviha...@wso2.com> wrote:
>>>>
>>>>> Hi Chamila,
>>>>>
>>>>> Docker is not really a platform if you look at the semantics. If we
>>>>> create another YAML for docker under platform hierarchy then we have to
>>>>> duplicate every platform specific YAML files under product hierarchy. I
>>>>> don't think it's a good option for us.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis <chami...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Akila,
>>>>>>
>>>>>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>>>>>> sure about Rocket, however if there are no considerable data duplication
>>>>>> between Docker and a possible Rocket configuration data set, IMO we 
>>>>>> should
>>>>>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Chamila de Alwis
>>>>>> Committer and PMC Member - Apache Stratos
>>>>>> Software Engineer | WSO2 | +94772207163
>>>>>> Blog: code.chamiladealwis.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>>>>>> raviha...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It seems "vm_type" hierarchy should exist to build Docker images
>>>>>>> (provisioned via Puppet) and then run on bare Docker. Because when 
>>>>>>> building
>>>>>>> the images for default platform (which is the option for bare Docker),
>>>>>>> there should be a separate hierarchy to set the installation_dir 
>>>>>>> parameter
>>>>>>> to "/mnt".
>>>>>>>
>>>>>>> I think it makes sense to have a separate hierarchy to control the
>>>>>>> configuration data for containers or VMs since that is one layer below 
>>>>>>> the
>>>>>>> platform level in a deployment infrastructure. For eg: we can have a
>>>>>>> Kubernetes platform with Docker as the container technology OR it could 
>>>>>>> be
>>>>>>> even Rocket. Inside this whatever vm_type we can ha

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Lakmal,

Hierarchy will be the same (hiera.yaml). You need to set docker-compose
specific configuration in "vm_type/docker-compose.yaml" file. This is for
when building the image. Puppet cannot handle run time configuration in
container scenario. If there is no platform (Mesos, K8s etc.) involved then
no need to create platform specific yaml files.

I think hiera.yaml should be abstract and flexible enough that a user
should be able to deploy WSO2 products/services on any platform or
container/VM type without changing it. Of course there can be custom
requirements. But this should suffice for most cases.

Thanks.

Thanks.

On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana <lak...@wso2.com>
wrote:

> Say I want to use in docker-compose (with pure docker). What hiera files
> (config) I have to use?
>
> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis <chami...@wso2.com>
> wrote:
>
>> I agree. Let's keep vm_type for simplicity.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Docker is not really a platform if you look at the semantics. If we
>>> create another YAML for docker under platform hierarchy then we have to
>>> duplicate every platform specific YAML files under product hierarchy. I
>>> don't think it's a good option for us.
>>>
>>> Thanks.
>>>
>>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis <chami...@wso2.com>
>>> wrote:
>>>
>>>> Hi Akila,
>>>>
>>>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>>>> sure about Rocket, however if there are no considerable data duplication
>>>> between Docker and a possible Rocket configuration data set, IMO we should
>>>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>>>
>>>>
>>>> Regards,
>>>> Chamila de Alwis
>>>> Committer and PMC Member - Apache Stratos
>>>> Software Engineer | WSO2 | +94772207163
>>>> Blog: code.chamiladealwis.com
>>>>
>>>>
>>>>
>>>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>>>> raviha...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems "vm_type" hierarchy should exist to build Docker images
>>>>> (provisioned via Puppet) and then run on bare Docker. Because when 
>>>>> building
>>>>> the images for default platform (which is the option for bare Docker),
>>>>> there should be a separate hierarchy to set the installation_dir parameter
>>>>> to "/mnt".
>>>>>
>>>>> I think it makes sense to have a separate hierarchy to control the
>>>>> configuration data for containers or VMs since that is one layer below the
>>>>> platform level in a deployment infrastructure. For eg: we can have a
>>>>> Kubernetes platform with Docker as the container technology OR it could be
>>>>> even Rocket. Inside this whatever vm_type we can have any base operating
>>>>> system running. So I've refined the hierarchy as follows;
>>>>>
>>>>> :hierarchy:
>>>>> - "node/%{::clientcert}"
>>>>> - 
>>>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>>>> - "osfamily/%{::osfamily}"
>>>>> - "vm_type/%{::vm_type}"
>>>>> - "platform/%{::platform}"
>>>>> - wso2/common
>>>>> - common
>>>>> :backends:
>>>>> - yaml
>>>>> :yaml:
>>>>> :datadir: "hieradata/%{::environment}"
>>>>>
>>>>> Since "wso2/common" and "common" are static hierarchies, those should
>>>>> be moved to the bottom. Please raise any concerns you may have with this
>>>>> hierarchy.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis <ch

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Chamila,

Docker is not really a platform if you look at the semantics. If we create
another YAML for docker under platform hierarchy then we have to duplicate
every platform specific YAML files under product hierarchy. I don't think
it's a good option for us.

Thanks.

On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis <chami...@wso2.com> wrote:

> Hi Akila,
>
> Why don't we use Docker as a platform rather than a vm_type? I'm not sure
> about Rocket, however if there are no considerable data duplication between
> Docker and a possible Rocket configuration data set, IMO we should keep the
> hierarchy simple and include Docker as a platform. WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> It seems "vm_type" hierarchy should exist to build Docker images
>> (provisioned via Puppet) and then run on bare Docker. Because when building
>> the images for default platform (which is the option for bare Docker),
>> there should be a separate hierarchy to set the installation_dir parameter
>> to "/mnt".
>>
>> I think it makes sense to have a separate hierarchy to control the
>> configuration data for containers or VMs since that is one layer below the
>> platform level in a deployment infrastructure. For eg: we can have a
>> Kubernetes platform with Docker as the container technology OR it could be
>> even Rocket. Inside this whatever vm_type we can have any base operating
>> system running. So I've refined the hierarchy as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "osfamily/%{::osfamily}"
>> - "vm_type/%{::vm_type}"
>> - "platform/%{::platform}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>> Since "wso2/common" and "common" are static hierarchies, those should be
>> moved to the bottom. Please raise any concerns you may have with this
>> hierarchy.
>>
>> Thanks.
>>
>>
>>
>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis <chami...@wso2.com>
>> wrote:
>>
>>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>>> stands for.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
>>>> Hi Chamila,
>>>>
>>>> Agreed. I don't think there would be anymore files in addition to
>>>> common.yaml here. How about moving this to root level; for eg:
>>>> "platform/kubernetes.yaml" ?
>>>>
>>>> Full Hierarchy will be as follows;
>>>>
>>>> :hierarchy:
>>>> - "node/%{::clientcert}"
>>>> - 
>>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>>> - "platform/%{::platform}"
>>>> - "osfamily/%{::osfamily}"
>>>> - wso2/common
>>>> - common
>>>> :backends:
>>>> - yaml
>>>> :yaml:
>>>> :datadir: "hieradata/%{::environment}"
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis <chami...@wso2.com>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>>>>> Will there be a YAML file in addition to the common.yaml?
>>>>>
>>>>> - "wso2/%{::platform}"
>>>>>
>>>>>
>>>>> Regards,
>>>>> Chamila de Alwis
>>>>> Committer and PMC Member - Ap

Re: [Dev] [DEV][Puppet Modules] Finalizing wso2/puppet-modules 2.0.0 release

[Akila Ravihansa Perera]

Hi Chamila,

We had to bring back "vm_type" because it is needed for bare Docker
scenario. Please refer to the other thread on wso2-dev list for a detailed
explanation.

I've also fixed Puppet Lint issues in all modules. There are 2 warnings
remaining though, as follows;

WARNING: class inherits across module namespaces
WARNING: line has more than 80 characters

We knew about class inheritance issue from the beginning and decided to go
with it anyway. Line max length of 80 is being enforced by Lint. But that
won't have a big impact I think.

Thanks.


On Mon, May 9, 2016 at 10:31 PM, Chamila De Alwis <chami...@wso2.com> wrote:

> Hi,
>
> Let's finalize the wso2/puppet-modules [1] 2.0.0 release. Following are
> the features and fixes implemented in this release.
>
>
>-
>
>Updated Hiera data hierarchy to include deployment platform
>-
>
>Kubernetes based workflow supported, based on wso2/kubernetes-artifacts
>-
>
>system_file_list to copy files with scope outside of CARBON_HOME
>-
>
>Platform specific configuration data sets for Kubernetes
>-
>
>   Kubernetes deployment-ready Puppet modules
>   -
>
>   Data sources matching a distributed set of Kubernetes MySQL Services
>   -
>
>Streamlined Default platform YAML configuration data
>-
>
>Optional update flags to control product pack and JDK cleanup
>-
>
>Minor fixes on the Hiera data
>-
>
>   Issues in YAML file formatting
>   -
>
>   Puppet templates for identity.xml added to relevant products
>   -
>
>   Proxy Port values assigned to different products are streamlined
>   -
>
>   Hostname entries streamlined in default deployment platform data set
>   -
>
>   Pass Through Port Mapping for WSO2 ESB
>   -
>
>   Fixing Thrift Server IP configuration for WSO2 MB
>   -
>
>   SecureVault parameters made optional
>   -
>
>WSO2 API Manager Gateway Manager-Worker separate profiles in Hieradata
>-
>
>WSO2 PPaaS Puppet module and Hiera data removed
>-
>
>vm_type level in the Hiera hierarchy removed
>- Improve Puppet Vagrant setup to use PUPPET_HOME environment variable
>
>
> The Hiera hierarchy is incompatible with the 1.x.x releases, as new levels
> are introduced with the features.
>
> Following are the tasks that should be completed to finalize the release.
>
>- Smoke test each product on the default platform for the default
>profile
>- Smoke test each product on the Kubernetes platform with clustering
>- Fix minor issues found during testing the products
>   - Consistent structure of the YAML file
>   - Style corrections
>   - Missing values that are crucial for product functionality from a
>   Smoke test's point of view
>- Improve and verify the README content
>
> Please refrain from implementing new features that are not fixing critical
> issues.
>
> You can use the following style guide [2] for YAML files in
> wso2/puppet-modules to streamline and format any YAML files that are
> inconsistent.
>
> Furthermore, please share details on the work you are doing and update as
> they are completed.
>
> [1] - https://github.com/wso2/puppet-modules
> [2] -
> https://docs.google.com/document/d/14fblI46ztAwFoq0YR5HjFeloj1jFVBxnuAl-aZ4Ropk/edit?usp=sharing
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>


-- 
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

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi,

It seems "vm_type" hierarchy should exist to build Docker images
(provisioned via Puppet) and then run on bare Docker. Because when building
the images for default platform (which is the option for bare Docker),
there should be a separate hierarchy to set the installation_dir parameter
to "/mnt".

I think it makes sense to have a separate hierarchy to control the
configuration data for containers or VMs since that is one layer below the
platform level in a deployment infrastructure. For eg: we can have a
Kubernetes platform with Docker as the container technology OR it could be
even Rocket. Inside this whatever vm_type we can have any base operating
system running. So I've refined the hierarchy as follows;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "osfamily/%{::osfamily}"
- "vm_type/%{::vm_type}"
- "platform/%{::platform}"
- wso2/common
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"

Since "wso2/common" and "common" are static hierarchies, those should be
moved to the bottom. Please raise any concerns you may have with this
hierarchy.

Thanks.



On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis <chami...@wso2.com> wrote:

> +1, IMO that's better since now it's clear how what kubernetes.yaml stands
> for.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Agreed. I don't think there would be anymore files in addition to
>> common.yaml here. How about moving this to root level; for eg:
>> "platform/kubernetes.yaml" ?
>>
>> Full Hierarchy will be as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "platform/%{::platform}"
>> - "osfamily/%{::osfamily}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Thanks.
>>
>>
>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis <chami...@wso2.com>
>> wrote:
>>
>>> +1
>>>
>>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>>> Will there be a YAML file in addition to the common.yaml?
>>>
>>> - "wso2/%{::platform}"
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We recently introduced a facter named "platform" to denote a PaaS
>>>> framework or cluster management system on which WSO2 products could be
>>>> deployed. With this addition I feel there is no reason to keep -
>>>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>>>> configuration parameters that is common across all the products for a
>>>> specific platform.
>>>>
>>>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>>>> membership scheme and related dependency jars for all the products. Also we
>>>> need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
>>>> because ipaddress is not available at the image build time.
>>>>
>>>> Therefore I'd like to propose that we include the
>>>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
>>>> this;
>>>>
>>>> :hierarchy:
>>>> - "node/%{::clientcert}"
>>>> - 
>>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>>> - "wso2/%{::platform}/common"
>>>> - wso2/common
>>>> - "osfamily/%{::osfamily}"
>>>> - common
>>>> :backends:
>>>> - yaml
>>>> :yaml:
>>>> :datadir: "hieradata/%{::environment}"
>>>>
>>>>
>>>> Any thoughts?
>>>>
>>>> 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
>>>>
>>>>
>>>
>>
>>
>> --
>> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Docker][Puppet] [MB] Setting 'thriftServerHost' in WSO2 MB broker.xml file

[Akila Ravihansa Perera]

.java:861)
>>>> at
>>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>>> at
>>>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>>>> at
>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
>>>> at
>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
>>>> at
>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
>>>> at
>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
>>>> at
>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
>>>> at
>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
>>>> at
>>>> org.wso2.carbon.core.init.CarbonServerManager.initializeCarbon(CarbonServerManager.java:514)
>>>> at
>>>> org.wso2.carbon.core.init.CarbonServerManager.removePendingItem(CarbonServerManager.java:290)
>>>> at
>>>> org.wso2.carbon.core.init.PreAxis2ConfigItemListener.bundleChanged(PreAxis2ConfigItemListener.java:118)
>>>> at
>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847)
>>>> at
>>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>>> at
>>>> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
>>>> Caused by: org.wso2.andes.kernel.AndesException: Cannot start Thrift
>>>> server on port 7611 on host wso2mb-default
>>>> at org.wso2.andes.thrift.MBThriftServer.start(MBThriftServer.java:87)
>>>> at
>>>> org.wso2.andes.kernel.AndesKernelBoot.startThriftServer(AndesKernelBoot.java:440)
>>>> at
>>>> org.wso2.andes.kernel.AndesKernelBoot.initializeComponents(AndesKernelBoot.java:93)
>>>> at org.wso2.andes.server.Broker.startupImpl(Broker.java:293)
>>>> ... 70 more
>>>> Caused by: org.apache.thrift.transport.TTransportException: Could not
>>>> create ServerSocket on address wso2mb-default/10.100.186.164:7611.
>>>> at
>>>> org.apache.thrift.transport.TServerSocket.(TServerSocket.java:109)
>>>> at
>>>> org.apache.thrift.transport.TServerSocket.(TServerSocket.java:91)
>>>> at
>>>> org.apache.thrift.transport.TServerSocket.(TServerSocket.java:87)
>>>> at org.wso2.andes.thrift.MBThriftServer.start(MBThriftServer.java:75)
>>>> ... 73 more
>>>> TID: [-1234] [] [2016-05-09 05:39:06,816]  INFO
>>>> {org.wso2.andes.server.registry.ApplicationRegistry} -  Shutting down
>>>> ApplicationRegistry(org.wso2.andes.server.registry.ConfigurationFileApplicationRegistry@70194966)
>>>> {org.wso2.andes.server.registry.ApplicationRegistry}
>>>>
>>>>
>>>> It's because currently  'thriftServerHost' is set to hostname in
>>>> broker.xml [1] and according to MB clustering guide [2] , this should be
>>>> set to MB node (docker container) IP which hosts the Thrift Server.
>>>>
>>>> If it's correct, what will be the best approach to update the
>>>> 'thriftServerHost' value with container IP?
>>>>
>>>> Please give your suggestions.
>>>>
>>>> [1].
>>>> https://github.com/wso2/puppet-modules/blob/master/modules/wso2mb/templates/3.1.0/repository/conf/broker.xml.erb#L37
>>>> [2].
>>>> https://docs.wso2.com/display/CLUSTER44x/Configuring+the+Broker+Nodes
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Thanuja Uruththirakodeeswaran
>>>> Software Engineer
>>>> WSO2 Inc.;http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 774363167
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> +94 716 358 048* <http://wso2.com/>*
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Darshana Akalanka Pagoda Arachchi,*
>> *Software Engineer, WSO2*
>> *+94777118016 <%2B94777118016>*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Pumudu Ruhunage
> Associate Software Engineer | WSO2 Inc
> M: +94 779 664493  | http://wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Chamila,

Agreed. I don't think there would be anymore files in addition to
common.yaml here. How about moving this to root level; for eg:
"platform/kubernetes.yaml" ?

Full Hierarchy will be as follows;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "platform/%{::platform}"
- "osfamily/%{::osfamily}"
- wso2/common
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"


Thanks.


On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis <chami...@wso2.com> wrote:

> +1
>
> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
> Will there be a YAML file in addition to the common.yaml?
>
> - "wso2/%{::platform}"
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> We recently introduced a facter named "platform" to denote a PaaS
>> framework or cluster management system on which WSO2 products could be
>> deployed. With this addition I feel there is no reason to keep -
>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>> configuration parameters that is common across all the products for a
>> specific platform.
>>
>> For eg: In Kubernetes platform, we need to copy the Kubernetes membership
>> scheme and related dependency jars for all the products. Also we need to
>> set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}" because
>> ipaddress is not available at the image build time.
>>
>> Therefore I'd like to propose that we include the
>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
>> this;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "wso2/%{::platform}/common"
>> - wso2/common
>> - "osfamily/%{::osfamily}"
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Any thoughts?
>>
>> 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
>>
>>
>


-- 
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

[Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi,

We recently introduced a facter named "platform" to denote a PaaS framework
or cluster management system on which WSO2 products could be deployed. With
this addition I feel there is no reason to keep - "vm_type/%{::vm_type}"
hierarchy. Also we need to way to introduce configuration parameters that
is common across all the products for a specific platform.

For eg: In Kubernetes platform, we need to copy the Kubernetes membership
scheme and related dependency jars for all the products. Also we need to
set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}" because
ipaddress is not available at the image build time.

Therefore I'd like to propose that we include the "wso2/%{platform}/common"
to the hierarchy. Full hiera.yaml would look like this;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "wso2/%{::platform}/common"
- wso2/common
- "osfamily/%{::osfamily}"
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"


Any thoughts?

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

Re: [Dev] WSO2 Dockerfiles 1.1.0 Released!

[Akila Ravihansa Perera]

Hi Vishanth,

It seems Dockerfiles 1.1.0 has been released with the wrong tag. It should
have been the last commit for Dockerfiles 1.1.0-rc1 which points to [1],
but the released tag v1.1.0 points to [2].

[1]
https://github.com/wso2/dockerfiles/commit/fb17893b468133f4f87464e823493ebec9250f4d
[2]
https://github.com/wso2/dockerfiles/commit/638c84edd8566c797c67736dade553f9e3820709

Thanks.




On Fri, May 6, 2016 at 5:11 PM, Vishanth Balasubramaniam <vishan...@wso2.com
> wrote:

> WSO2 PaaS team is pleased to announce the release of *WSO2 *
> *Dockerfiles 1.1.0.*
>
> WSO2 Dockerfiles 1.1.0 is the successor of 1.0.0. The main changes for
> this release:
>
>
>-
>
>An option flag in build script to skip confirmation for image
>overwriting
>-
>
>An option flag in build script to provide platform as an argument to
>build
>-
>
>An option flag in build script to tag name param in the build script
>-
>
>Fixing ‘IP command not found’ issue in puppet provisioning
>-
>
>Fixing ‘IP command not found’ issue by adding iproute2 to apt-get
>install
>-
>
>Added a root build script to build all docker images with default
>provisioning
>-
>
>Added a script to clean all the docker images built with default
>provisioning
>-
>
>Export CARBON_HOME before calling the profile init script
>-
>
>Option to prompt container logs in docker run script
>-
>
>Pick port between 8000 - 8010 for the http server
>- Corrected container_id variable name
>
>
> Release artifacts:
>
> https://github.com/wso2/dockerfiles/releases/tag/v1.1.0
>
>
> Documentation:
>
> https://docs.wso2.com/display/DF110/WSO2+Dockerfiles+Documentation
>
>
> Known Issues:
>
> https://github.com/wso2/dockerfiles/issues
>
>
>
> Thank you,
> Vishanth on behalf of WSO2 PaaS Team.
>
> --
> *Vishanth Balasubramaniam*
> Committer & PMC Member, Apache Stratos,
> Software Engineer, WSO2 Inc.; http://wso2.com
>
> mobile: *+94 77 17 377 18*
> about me: *http://about.me/vishanth <http://about.me/vishanth>*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [wso2/puppet-modules] Puppet CERT error

[Akila Ravihansa Perera]

Hi,

Looks like Puppet agent cannot resolve the hostname set in puppet.conf.
Please check whether correct hostname is set in puppet.conf and that it is
resolvable via DNS or /etc/hosts file.

Also make sure hostname is correctly set in Puppet master. Output of
`hostname` command should match the value in puppet.conf.

Thanks.

On Tue, Feb 23, 2016 at 2:10 PM, Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

> The problem was I didn't have a directory for my APIM version in
> *hieradata/production/wso2/wso2am.* Thanks a lot Akila for helping me a
> lot offline.
>
> But unfortunately I'm still away from success. Now I'm getting below
> error. Any idea about the cause?
>
> root@apim-node-1:/opt# ./setup.sh
> #
>Starting cleanup
> #
> #
>Setting up environment
> #
> #
> Installing
> #
> Warning: Unable to fetch my node definition, but the agent run will
> continue:
> Warning: getaddrinfo: Name or service not known
> Info: Retrieving plugin
> Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources
> using 'eval_generate': getaddrinfo: Name or service not known
> Error: /File[/var/lib/puppet/lib]: Could not evaluate: getaddrinfo: Name
> or service not known Could not retrieve file metadata for
> puppet://puppet/plugins: getaddrinfo: Name or service not known
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/service_provider.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/package_provider.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Error: Could not retrieve catalog from remote server: getaddrinfo: Name or
> service not known
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> Error: Could not send report: getaddrinfo: Name or service not known
>
> Thanks,
> Bhathiya
>
> On Tue, Feb 23, 2016 at 10:44 AM, Bhathiya Jayasekara <bhath...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> Thanks for the replies. The problem was the hostname as Lahiru mentioned.
>> I didn't restart the VM after changing /etc/hostname before. Just restarted
>> the VM now and issue is solved. I think it's better to update the doc if a
>> restart is required after changing hostname.
>>
>> However I endedup in another error..
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Could not find data item classes in any Hiera data file and no
>> default supplied at
>> /etc/puppet/environments/production/manifests/site.pp:21 on node
>> apim-node-1.openstacklocal
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>> As mentioned in the doc, I have that site.pp in puppet master only. Do I
>> need to have it in agent too?
>>
>> Thanks,
>> Bhathiya
>>
>>
>>
>> On Tue, Feb 23, 2016 at 9:34 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Bhathiya,
>>>
>>> Please try the following steps;
>>>
>>> 1. Delete all certificates in Puppet master (rm -rf
>>> /var/lib/puppet/ssl/*)
>>> 2. Delete all certificates in Puppet agent (rm -rf /var/lib/puppet/ssl/*)
>>> You may use `puppet cert clean --all` command as well
>>>
>>> 3. Check puppet.conf in both Puppet agent and master
>>> Agent should point to master hostname
>>> server = puppet.example.com
>>>
>>> This hostname must resolve to corresponding IP address via DNS or hosts
>>> file mappings
>>>
>>> This hostname must be the Puppet master's system hostname. Or else it
>>> should be added as a property to puppet.conf in Puppet master instance
>>>
>>> dns_alt_names=puppet.example.com
>>>
>>> 4. Auto-signing should be enabled in puppet.conf in Puppet master. Or
>>> all the white-listed hostnames should be added to autosign.conf in Puppet
>>> master.
>>> autosign = true
>>>
>>> 5. Restart Puppet master service after modifying above config files.
>>>
>>> Thanks.
>>>
>>> On Tue, F

Re: [Dev] [wso2/puppet-modules] Puppet CERT error

[Akila Ravihansa Perera]

erver
>>>>> certificate B: certificate verify failed: [certificate revoked for
>>>>> /CN=apim-2.openstacklocal]
>>>>> Info: Retrieving plugin
>>>>> Error: /File[/var/lib/puppet/lib]: Failed to generate additional
>>>>> resources using 'eval_generate': SSL_connect returned=1 errno=0 
>>>>> state=SSLv3
>>>>> read server certificate B: certificate verify failed: [certificate revoked
>>>>> for /CN=apim-2.openstacklocal]
>>>>> Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect
>>>>> returned=1 errno=0 state=SSLv3 read server certificate B: certificate
>>>>> verify failed: [certificate revoked for /CN=apim-2.openstacklocal] Could
>>>>> not retrieve file metadata for puppet://puppet/plugins: SSL_connect
>>>>> returned=1 errno=0 state=SSLv3 read server certificate B: certificate
>>>>> verify failed: [certificate revoked for /CN=apim-2.openstacklocal]
>>>>> Error: Could not retrieve catalog from remote server: SSL_connect
>>>>> returned=1 errno=0 state=SSLv3 read server certificate B: certificate
>>>>> verify failed: [certificate revoked for /CN=apim-2.openstacklocal]
>>>>> Warning: Not using cache on failed catalog
>>>>> Error: Could not retrieve catalog; skipping run
>>>>> Error: Could not send report: SSL_connect returned=1 errno=0
>>>>> state=SSLv3 read server certificate B: certificate verify failed:
>>>>> [certificate revoked for /CN=apim-2.openstacklocal]
>>>>>
>>>>> [1]
>>>>> https://github.com/wso2/puppet-modules/wiki/Use-WSO2-Puppet-Modules-in-puppet-master-agent-Environment
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> *Bhathiya Jayasekara*
>>>>> *Senior Software Engineer,*
>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>
>>>>> *Phone: +94715478185 <%2B94715478185>*
>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>> <https://twitter.com/bhathiyax>*
>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Pubudu Gunatilaka*
>>>> Committer and PMC Member - Apache Stratos
>>>> Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> mobile : +94774079049 <%2B94772207163>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Senior Software Engineer,*
>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>
>>> *Phone: +94715478185 <%2B94715478185>*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> <http://www.linkedin.com/in/bhathiyaj>*
>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>>> *Blog: http://movingaheadblog.blogspot.com
>>> <http://movingaheadblog.blogspot.com/>*
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Sajith Kariyawasam
>> *Committer and PMC member, Apache Stratos, *
>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>> *Mobile: 0772269575 <0772269575>*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> phone: +94773325954
> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

[Dev] Improvements to WSO2 Puppet Modules

[Akila Ravihansa Perera]

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_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

Re: [Dev] puppet modules - validating yaml files

[Akila Ravihansa Perera]

Great thought Sajith.

I also had an idea to add puppet-lint check to maven ant plugin. Shall we
do the same for YAML validation?

Basically we run your Python script and Puppet lint command for each Puppet
module. If there are any errors the maven build should fail. Also it should
print the list of files which violate the rules. wdyt?

Thanks.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.1 RC2

[Akila Ravihansa Perera]

[x] Stable - go ahead and release

Tested following;
 - PHP application deployment, activation and undeployment on Kubernetes
 - Scale up functionality
 - Faulty member detection
 - Tested APIM 1.9.1 cartridge (IS as KM) with PPaaS on Kubernetes
 - Tested sample application on AWS EC2 IaaS


Found a minor error in one of the samples in ppaas-cartridges repo [1].

[1]
https://github.com/wso2/private-paas-cartridges/blob/v4.1.3/wso2am/1.9.1/samples/kubernetes-clusters/kubernetes-cluster-1.json#L53

On Mon, Dec 28, 2015 at 7:55 PM, Thanuja Uruththirakodeeswaran <
thanu...@wso2.com> wrote:

> +1 for the release
>
> Tested ppaas in kubernetes with few wso2 product cartridges along metering
> and monitering feature.
>
> Thanks.
>
> On 27 Dec 2015 21:12, "Gayan Gunarathne" <gay...@wso2.com
> ) wrote:))
>
> >
> >
> >
> > On Sun, Dec 27, 2015 at 10:00 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
> >>
> >> Hi Gayan,
> >>
> >> Since we have forked Python cartridge agent in PPaaS 4.1.1-RC2, users
> won't be able to use Dockerfile shipped with Stratos to build cartridge
> images.
> >
> > What do you mean by Dockerfile shipped with Stratos?
> >
> >>
> >> Have we documented the steps needed to build cartridge Docker images
> for PPaaS?
> >
> > We are released the Cartridges based on the PPaaS release version.
> Currently released cartridges are compatible with PPaaS 4.1.0 release.With
> the PPaaS 4.1.1 released our documentation need to be changed in the case
> of user using the PPaaS 4.1.1 release
> >>
> >>
> >> Thanks.
> >>
> >> On Fri, Dec 25, 2015 at 12:06 AM, Gayan Gunarathne <gay...@wso2.com>
> wrote:
> >>>
> >>> IMO if the vote is success we can simply move those binaries to the
> product distribution without doing any alternation to those binaries.This
> is the same as the staging repo. If the vote is success we promote the
> staging repo , if it is fails we drop that staging repo.
> >>>
> >>> Thanks,
> >>> Gayan
> >>>
> >>> On Thu, Dec 24, 2015 at 11:47 PM, Imesh Gunaratne <im...@wso2.com>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Dec 24, 2015 at 10:41 PM, Gayan Gunarathne <gay...@wso2.com>
> wrote:
> >>>>>
> >>>>> Hi Imesh,
> >>>>>
> >>>>> What is the ration behind that? I don't see any reason to prefix
> binaries with the release candidate no. As those binaries will be the one
> which move to the product release distribution if the vote is success,
> >>>>>
> >>>> The only concern is once we do multiple release candidates, how would
> someone differentiate those if we have the same set of file names?
> >>>>
> >>>> Thanks
> >>>>
> >>>>> Thanks,
> >>>>> Gayan
> >>>>>
> >>>>> On Thu, Dec 24, 2015 at 10:14 PM, Imesh Gunaratne <im...@wso2.com>
> wrote:
> >>>>>>
> >>>>>> Hi Gayan,
> >>>>>>
> >>>>>> I think all the distributions should get prefixed with rc2, see
> 4.1.0-rc2:
> >>>>>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc2/
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> On Mon, Dec 21, 2015 at 7:35 PM, Gayan Gunarathne <gay...@wso2.com>
> wrote:
> >>>>>>>
> >>>>>>>  Hi All,
> >>>>>>>
> >>>>>>> This is the second release candidate of WSO2 Private PaaS 4.1.1.
> >>>>>>>
> >>>>>>> This release fixes the following issues:
> >>>>>>> https://wso2.org/jira/browse/PAAS-305?filter=12582
> >>>>>>>
> >>>>>>> Please download, test and vote. The vote will be open for 72 hours
> or as needed.
> >>>>>>>
> >>>>>>> ​Source and binary distribution files:
> >>>>>>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.1-rc2/
> >>>>>>>
> >>>>>>> Maven staging repository:
> >>>>>>>
> >>>>>>> http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-217/
> >>>>>>>
> >>>>>>> The tag to be voted upon:
> >>>>>>&g

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.1 RC2

[Akila Ravihansa Perera]

Hi Gayan,

Since we have forked Python cartridge agent in PPaaS 4.1.1-RC2, users won't
be able to use Dockerfile shipped with Stratos to build cartridge images.
Have we documented the steps needed to build cartridge Docker images for
PPaaS?

Thanks.

On Fri, Dec 25, 2015 at 12:06 AM, Gayan Gunarathne <gay...@wso2.com> wrote:

> IMO if the vote is success we can simply move those binaries to the
> product distribution without doing any alternation to those binaries.This
> is the same as the staging repo. If the vote is success we promote the
> staging repo , if it is fails we drop that staging repo.
>
> Thanks,
> Gayan
>
> On Thu, Dec 24, 2015 at 11:47 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>>
>>
>> On Thu, Dec 24, 2015 at 10:41 PM, Gayan Gunarathne <gay...@wso2.com>
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> What is the ration behind that? I don't see any reason to prefix
>>> binaries with the release candidate no. As those binaries will be the one
>>> which move to the product release distribution if the vote is success,
>>>
>>> The only concern is once we do multiple release candidates, how would
>> someone differentiate those if we have the same set of file names?
>>
>> Thanks
>>
>> Thanks,
>>> Gayan
>>>
>>> On Thu, Dec 24, 2015 at 10:14 PM, Imesh Gunaratne <im...@wso2.com>
>>> wrote:
>>>
>>>> Hi Gayan,
>>>>
>>>> I think all the distributions should get prefixed with rc2, see
>>>> 4.1.0-rc2:
>>>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc2/
>>>>
>>>> Thanks
>>>>
>>>> On Mon, Dec 21, 2015 at 7:35 PM, Gayan Gunarathne <gay...@wso2.com>
>>>> wrote:
>>>>
>>>>>  Hi All,
>>>>>
>>>>> This is the second release candidate of WSO2 Private PaaS 4.1.1.
>>>>>
>>>>> This release fixes the following issues:
>>>>> *https://wso2.org/jira/browse/PAAS-305?filter=12582
>>>>> <https://wso2.org/jira/browse/PAAS-305?filter=12582>*
>>>>>
>>>>> Please download, test and vote. The vote will be open for 72 hours or
>>>>> as needed.
>>>>>
>>>>> *​Source and binary distribution files:*
>>>>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.1-rc2/
>>>>>
>>>>> *Maven staging repository:*
>>>>>
>>>>> http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-217/
>>>>>
>>>>> *The tag to be voted upon:*
>>>>> https://github.com/wso2/product-private-paas/tree/v4.1.1-rc2
>>>>>
>>>>>
>>>>> [ ] Broken - do not release (explain why)
>>>>> [ ] Stable - go ahead and release
>>>>>
>>>>>
>>>>> Thanks,
>>>>> The WSO2 Private PaaS Team
>>>>>
>>>>> --
>>>>>
>>>>> Gayan Gunarathne
>>>>> Technical Lead, WSO2 Inc. (http://wso2.com)
>>>>> Committer & PMC Member, Apache Stratos
>>>>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Imesh Gunaratne*
>>>> Senior Technical Lead
>>>> WSO2 Inc: http://wso2.com
>>>> T: +94 11 214 5345 M: +94 77 374 2057
>>>> W: http://imesh.gunaratne.org
>>>> Lean . Enterprise . Middleware
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Gayan Gunarathne
>>> Technical Lead, WSO2 Inc. (http://wso2.com)
>>> Committer & PMC Member, Apache Stratos
>>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>>
>>>
>>>
>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.gunaratne.org
>> Lean . Enterprise . Middleware
>>
>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead, WSO2 Inc. (http://wso2.com)
> Committer & PMC Member, Apache Stratos
> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [Hiera] Deeper hash merge instead of Native hash merge?

[Akila Ravihansa Perera]

Hi Raj,

It is true that native hash merging has its own limitations which would
lead to data duplication in some cases. But we need to analyze the
trade-off between data duplication against readability and trace-ability
aspects. IMHO, it's okay to have few data duplication if it makes things
more simple and less error prone.

My concern is that what if this accidentally leads to unexpected data
merging? I understand that native merging will merge the top level keys as
well, but that is less susceptible for human errors compared to N-level
deep merge.

Also have a look at Puppet official docs about deep merging [1]. Looks like
it is mainly intended for complex data structures and converting them to
Puppet resources.

We can ask the users to create their own Hiera data structures with deeper
merging if they are comfortable with it. But given the additional
complexity involved in configuring and installing deep_merge library [2],
shall we ship native merge data structures by default?

[1]
https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera
[2]
https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera

Thanks.

On Fri, Dec 25, 2015 at 10:45 AM, Rajkumar Rajaratnam <rajkum...@wso2.com>
wrote:

> Hi Devs,
>
> We are using *Native* hash merge right now. *It merges only the top-level
> keys and values in each source hash. If the same key exists in both a lower
> priority source and a higher priority source, the higher priority value
> will be used. *But it doesn't allow us to override a nested hash.
>
> Lets take an example,
>
> *hiera.yaml*
>
> ---
> :hierarchy:
> - "wso2/%{::product_name}/%{::product_version}/default"
> - wso2/common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
> *wso2/common.yaml*
>
> ---
> # Deployment synchronization configuration
> wso2::dep_sync :
> enabled : false
> auto_checkout : true
> auto_commit : false
> repository_type : svn
> svn :
>   url : http://svnrepo.example.com/repos/
>user : username
>password : password
>append_tenant_id: true
>
> *wso2/wso2esb/4.9.0/default.yaml*
>
> ---
> wso2::dep_sync :
> enabled : true
> svn :
>   url : http://rajkumar.com/repos/
>
>
> *Native* hash merge would return the following;
>
> {
>"enabled"   =>true,
>"auto_checkout"   =>true,
>"auto_commit"   =>false,
>"repository_type"   =>"svn",
>"svn"   =>   {
>   "url"  =>"http://rajkumar.com/repos/;
>}
> }
>
> *Deeper* hash merge would return the following;
>
> {
>"enabled"   =>true,
>"auto_checkout"   =>true,
>"auto_commit"   =>false,
>"repository_type"   =>"svn",
>"svn"   =>   {
>   "url"  =>"http://rajkumar.com/repos/;,
>   "user"  =>"username",
>   "password"  =>"password",
>   "append_tenant_id"  =>true
>}
> }
>
>
> If we use *Native* hash merging, we need to copy the complete nested hash
> ("svn" in above example) and override it. If we use *Deeper* hash
> merging, we can copy only a part of a nested hash and override it. As you
> can see, *Deeper* hash merge reduces data duplication.
>
> Thoughts please.
>
> Thanks,
> Raj.
>
> --
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
>



-- 
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

Re: [Dev] PPaaS Artifact Migration Tool

[Akila Ravihansa Perera]

to be compatible with PPaaS 4.1.0. [1]
>>>>
>>>> We have implemented the conversions for the following artifacts ;
>>>>- auto scale policy artifacts
>>>>- network partition list artifacts
>>>>- deployment policy artifacts
>>>>- cartridge artifacts
>>>>
>>>> Now we are implementing the conversion of cartridge subscription
>>>> artifacts to application signups and domain mapping subscriptions.
>>>>
>>>> Please raise if there are any concerns regarding this work.
>>>>
>>>> [1]
>>>> https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter
>>>>
>>>> Thanks
>>>> Nishadi
>>>>
>>>> --
>>>> Nishadi Kirielle
>>>> *Software Engineering Intern*
>>>> Mobile : +94 (0) 714722148
>>>> nish...@wso2.com
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Gayan Gunarathne
>>> Technical Lead, WSO2 Inc. (http://wso2.com)
>>> Committer & PMC Member, Apache Stratos
>>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Nishadi Kirielle
> *Software Engineering Intern*
> Mobile : +94 (0) 714722148
> nish...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] Locating the Artifact Converter Tool in WSO2 Product-Private-PaaS Repo

[Akila Ravihansa Perera]

Hi,

+1 for the proposed folder structure.

@Gayan: Currently that tool only exports existing cartridge subscriptions
and domain mappings. It doesn't do any conversion or migration (although it
is called migration-tool); which is why it should be renamed to
subscription-manager. I actually prefer the name "subscription-exporter".
We had to create an external tool since regular API didn't have any methods
to expose those information. We should include those API methods to the
regular API in the new PPaaS release.

@Malmee: I've restructured the folder structure in [1]. You can create a
new folder named "artifact-converter" at tools/migration/ to host your
tool. Please send a PR with those changes.

On a side note; does your tool support converting cartridge subscription
artifacts to application signups and domain mapping subscriptions?

[1] https://github.com/wso2/product-private-paas/tree/master/tools/migration

Thanks.

On Tue, Dec 1, 2015 at 6:23 PM, Imesh Gunaratne <im...@wso2.com> wrote:

>
>
> On Tue, Dec 1, 2015 at 5:23 PM, Gayan Gunarathne <gay...@wso2.com> wrote:
>
>>
>> On Tue, Dec 1, 2015 at 4:46 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>> Shall we have something like below:
>>>
>>> └── tools
>>> └── migration
>>> ├── artifact-converter
>>> └── subcription-manager
>>>
>>
>> I think it is a subscription-converter not subscription-manager.It will
>> convert the 4.0.0 subscriptions to the 4.1.0. So shall we call it as
>> subscription-converter?
>>
>
> AFAIK it does not convert subscriptions, it just export them.
>
> Thanks
>
>>
>>> @Akila: We might need to rename the existing subscription management
>>> tool.
>>>
>>> Thanks
>>>
>>> On Tue, Dec 1, 2015 at 3:37 PM, Malmee Weerasinghe <mal...@wso2.com>
>>> wrote:
>>>
>>>> Hi Akila,
>>>> We need to locate the Artifact Converter Tool which converts PPaaS
>>>> 4.0.0 artifacts to PPaaS 4.1.0, in Product-Private-PaaS Repo.
>>>>
>>>> As Artifact Converter Tool and paas-migration/4.0.0 tool have quite
>>>> similar functionality, can we create a new folder in 'tools' and move
>>>> paas-migration/4.0.0 tool to it and locate together with Artifact
>>>> Converter Tool. Do you have any suggestions?
>>>>
>>>> Thank you
>>>> --
>>>> Malmee Weerasinghe
>>>> WSO2 Intern
>>>> mobile : (+94)* 71 7601905* |   email :   <dehan.vith...@aiesec.net>
>>>> mal...@wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Senior Technical Lead
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: http://imesh.gunaratne.org
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> Gayan Gunarathne
>> Technical Lead, WSO2 Inc. (http://wso2.com)
>> Committer & PMC Member, Apache Stratos
>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>
>>
>>
>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] [PPaaS] Docker base image creation scirpt

[Akila Ravihansa Perera]

>
> More importantly [2] explains why root permission is needed and how sudo
> can be avoided by adding the user to docker group (not sudoers group).
>
> *The docker daemon always runs as the root user, and since Docker version
> 0.5.2, the docker daemon binds to a Unix socket instead of a TCP port. By
> default that Unix socket is owned by the user root, and so, by default, you
> can access it with sudo.*
>
> *Starting in version 0.5.3, if you (or your Docker installer) create a
> Unix group called docker and add users to it, then the docker daemon will
> make the ownership of the Unix socket read/writable by the docker group
> when the daemon starts. The docker daemon must always run as the root user,
> but if you run the docker client as a user in the docker group then you
> don't need to add sudo to all the client commands. As of 0.9.0, you can
> specify that a group other than docker should own the Unix socket with the
> -G option.*
>
>

+1
Let's remove sudo from docker commands. Perhaps check whether docker
command is accessible or else print a warning message.

Thanks Imesh for pointing this out :)


>
> [1]
> http://askubuntu.com/questions/425754/how-do-i-run-sudo-command-inside-a-script/425990#425990
> [2]
> http://askubuntu.com/questions/477551/how-can-i-use-docker-without-sudo
>
> Thanks
>
>
>>  Thanks.
>>
>>
>>>
>>>> Does anyone aware of how to execute docker termination from Docker
>>>> Quickstart Terminal with sudo permission?
>>>>
>>>> Try to do a sudo docker ps
>>> sudo docker ps
>>> sudo docker rm -f [container id]
>>>
>>> Thanks
>>>
>>>
>>>> Thanks,
>>>> Reka
>>>>
>>>> On Mon, Nov 9, 2015 at 8:05 PM, Gayan Gunarathne <gay...@wso2.com>
>>>> wrote:
>>>>
>>>>> The command that we used to retrieve the configurator_version is not
>>>>> working as we don't have a pom in the base-image.May be we get
>>>>> the configurator_version from parent pom and but seems that command is not
>>>>> working when we point to the parent pom.We may not need to read
>>>>> this configurator_version from the pom?
>>>>>
>>>>> [1]
>>>>> https://github.com/wso2/private-paas-cartridges/blob/master/common/docker/base-image/build.sh#L25
>>>>>
>>>>> Thanks,
>>>>> Gayan
>>>>>
>>>>> --
>>>>>
>>>>> Gayan Gunarathne
>>>>> Technical Lead, WSO2 Inc. (http://wso2.com)
>>>>> Committer & PMC Member, Apache Stratos
>>>>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Reka Thirunavukkarasu
>>>> Senior Software Engineer,
>>>> WSO2, Inc.:http://wso2.com,
>>>> Mobile: +94776442007
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Senior Technical Lead
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: http://imesh.gunaratne.org
>>> Lean . Enterprise . Middleware
>>>
>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>


-- 
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

Re: [Dev] [PPaaS] Docker base image creation scirpt

[Akila Ravihansa Perera]

Hi,


On Mon, Nov 9, 2015 at 11:00 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
> We need to remove sudo from this command/bash script:
> sudo docker build -t wso2/base-image:${wso2_base_image_version} .
>
> If sudo is needed the entire script should be run in that mode.
>

I don't think entire script  needs to be run in sudo mode. There are some
maven build commands if run in sudo mode it will try to download artifacts
for root user's maven repo space. Also there are some file copy commands if
run in sudo mode it will mess up the ownership of folder structure.
Removing sudo mode from docker build command is a bad idea since it forces
users to either run in sudo mode or add Docker user to sudoers group which
is a security risk.

 Thanks.


>
>> Does anyone aware of how to execute docker termination from Docker
>> Quickstart Terminal with sudo permission?
>>
>> Try to do a sudo docker ps
> sudo docker ps
> sudo docker rm -f [container id]
>
> Thanks
>
>
>> Thanks,
>> Reka
>>
>> On Mon, Nov 9, 2015 at 8:05 PM, Gayan Gunarathne <gay...@wso2.com> wrote:
>>
>>> The command that we used to retrieve the configurator_version is not
>>> working as we don't have a pom in the base-image.May be we get
>>> the configurator_version from parent pom and but seems that command is not
>>> working when we point to the parent pom.We may not need to read
>>> this configurator_version from the pom?
>>>
>>> [1]
>>> https://github.com/wso2/private-paas-cartridges/blob/master/common/docker/base-image/build.sh#L25
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>>
>>> Gayan Gunarathne
>>> Technical Lead, WSO2 Inc. (http://wso2.com)
>>> Committer & PMC Member, Apache Stratos
>>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>


-- 
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

[Dev] [PPAAS] Introducing new WSO2 cartridges for PPAAS

[Akila Ravihansa Perera]

Hi,

We have introduced following set of new cartridges for WSO2 Private PaaS
compatible with version 4.1.0 or higher.

 - WSO2 ESB 4.9.0 cartridge
 - WSO2 AS 5.3.0 cartridge
 - WSO2 GREG 5.1.0 cartridge

These cartridges support worker manager deployments on EC2, OpenStack and
Kubernetes. Private PaaS membership scheme can be used for clustering.

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

Re: [Dev] WSO2 Private PaaS 4.1.0 EC2 Demo AMI

[Akila Ravihansa Perera]

Hi Gayan,

Please see my answers inline.

1. How can user select the products that user need to deploy with the PPaaS?
>

All cartridges released with Private PaaS cartridges 4.1.1 are added at the
instance startup. But the applications are not deployed (will be in CREATED
state). It is up to the user to login to the console and deploy the apps as
desired.


> 2. Are we using embedded CEP for health stats publishing?Can user select
> to external cep?
>

It is currently configured in single JVM mode with embedded CEP. Since this
is only a demo instance, no need to go for an external CEP I think.


> 3. AFAIR DAS is running in the same PPaaS instance.How can user enable
> disable the DAS metering and monitoring stuff?
>

DAS is running in the same instance with a port offset. It is enabled by
default. Since this is a demo AMI it is better to showcase all possible
features we have.


>
> May be we can have the demo image for only one region and if someone needs
> in the other region he can copy from there.
>

Yes, but I'm not sure whether AMIs can be directly copied from a region to
another region. Anyway it  is only a matter of copying those script files
and artifacts to create a demo AMI.

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

Re: [Dev] WSO2 Private PaaS 4.1.0 EC2 Demo AMI

[Akila Ravihansa Perera]

Hi Imesh,

The demo AMI is currently publicly available only in Asia Pacific
(Singapore) region.

AMI ID: ami-323dfa51
AMI Name: WSO2 Private PaaS 4.1.0 - Demo AMI


I've created a repo with all the scripts and template modules used to
create the demo AMI at [1]. Do we need to create AMI's for every region?
Since everything is scripted it's just a matter of copying those artifacts
to an instance in other regions.

[1] https://github.com/ravihansa3000/wso2ppaas-demo-ami

Thanks.



On Thu, Nov 5, 2015 at 1:07 AM, Imesh Gunaratne <im...@wso2.com> wrote:

> Great work Akila!!
> Indeed this is the most convenient method for users to try out WSO2
> Private PaaS 4.1.0 on AWS.
>
> A quick question, have we published the AMIs publicly in different
> regions? If so we can have a page in the Wiki mentioning them.
>
> @Mari: Shall we add this guideline to the documentation?
>
> Thanks
>
> On Wed, Nov 4, 2015 at 6:47 AM, Akila Ravihansa Perera <raviha...@wso2.com
> > wrote:
>
>> Hi,
>>
>> I've created an EC2 AMI preconfigured with WSO2 Private PaaS 4.1.0 and
>> WSO2 cartridges. The demo AMI contains init scripts to configure PPaaS,
>> ActiveMQ and Nginx load-balancer extension. You need to pass PPaaS specific
>> parameters as user data when launching this demo AMI and the init script
>> will configure the products, deploy artifacts and cartridges.
>> It will also configure WSO2 DAS with PPaaS gadgets which is used to
>> provide monitoring and metering related information.
>>
>>  This will be a very convenient method for users to get started with
>> Private PaaS since it reduces most of the configuration related tasks. I've
>> written a blog post [1] explaining how to setup WSO2 Private PaaS 4.1.0
>> with this demo AMI.
>>
>> [1]
>> http://blog.ravihansa3000.com/2015/11/deploying-wso2-private-paas-410-using.html
>>
>> Thanks.
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>


-- 
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

[Dev] WSO2 Private PaaS 4.1.0 EC2 Demo AMI

[Akila Ravihansa Perera]

Hi,

I've created an EC2 AMI preconfigured with WSO2 Private PaaS 4.1.0 and WSO2
cartridges. The demo AMI contains init scripts to configure PPaaS, ActiveMQ
and Nginx load-balancer extension. You need to pass PPaaS specific
parameters as user data when launching this demo AMI and the init script
will configure the products, deploy artifacts and cartridges.
It will also configure WSO2 DAS with PPaaS gadgets which is used to provide
monitoring and metering related information.

 This will be a very convenient method for users to get started with
Private PaaS since it reduces most of the configuration related tasks. I've
written a blog post [1] explaining how to setup WSO2 Private PaaS 4.1.0
with this demo AMI.

[1]
http://blog.ravihansa3000.com/2015/11/deploying-wso2-private-paas-410-using.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

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC2

[Akila Ravihansa Perera]

Tested samples apps on ec2 and Kubernetes platforms.

[x] Stable - go ahead and release

On Wed, Oct 21, 2015 at 11:00 AM, Gayan Gunarathne <gay...@wso2.com> wrote:

> Hi All,
>
> Please find the release candidate of the WSO2 PPaaS cartridges related to
> the WSO2 Private PaaS 4.1.0.
>
> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-cartridges-4.1.1/
>
> Please use these set of Cartridges to test the WSO2 Private PaaS 4.1.0
> release.
>
> Thanks,
> Gayan
>
> On Wed, Oct 21, 2015 at 8:05 AM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>> Hi Devs,
>>
>> This is the second release candidate of WSO2 Private PaaS 4.1.0.
>>
>> This release fixes the following issues:
>> https://wso2.org/jira/issues/?filter=12467
>>
>> Please download, test and vote. The vote will be open for 72 hours or as
>> needed.
>>
>> *​Source and binary distribution files:*
>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc2/
>>
>> *Maven staging repository:*
>> http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-028/
>>
>> *The tag to be voted upon:*
>> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc2
>>
>>
>> [ ] Broken - do not release (explain why)
>> [ ] Stable - go ahead and release
>>
>>
>> Thanks,
>> The WSO2 Private PaaS Team
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.gunaratne.org
>> Lean . Enterprise . Middleware
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead, WSO2 Inc. (http://wso2.com)
> Committer & PMC Member, Apache Stratos
> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] Missing links in WSO2 docker hub

[Akila Ravihansa Perera]

I purposely kept it like that since we have to change it anyway when we
release.

On Thu, Oct 22, 2015 at 1:49 PM, Pubudu Gunatilaka <pubu...@wso2.com> wrote:

> Hi,
>
> IMO it should refer to already released version which is 4.1.0 cartridge
> repo until 4.1.1 is released.
>
> Thank you!
>
> On Thu, Oct 22, 2015 at 1:45 PM, Gayan Gunarathne <gay...@wso2.com> wrote:
>
>> There are some missing github repo links with the WSO2 docker hub
>> pages[1]. Shall we link those to the master branch until  we do the PPaaS
>> Cartridge release?
>>
>> [1]https://hub.docker.com/r/wso2/as-5.2.1/
>>
>> Thanks,
>> Gayan
>>
>> --
>>
>> Gayan Gunarathne
>> Technical Lead, WSO2 Inc. (http://wso2.com)
>> Committer & PMC Member, Apache Stratos
>> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774079049 <%2B94772207163>
>
>


-- 
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

[Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC1

[Akila Ravihansa Perera]

Hi,

This is the first release candidate of WSO2 Private PaaS 4.1.0.

This release fixes the following issues:
https://wso2.org/jira/issues/?filter=12464

Please download, test and vote. The vote will be open for 72 hours or as
needed.

*​Source and binary distribution files:*
https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc1

*Maven staging repository:*
http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-027/

*The tag to be voted upon:*
https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1


[ ] Broken - do not release (explain why)
[ ] Stable - go ahead and release


Thanks,
The WSO2 Private PaaS Team
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC1

[Akila Ravihansa Perera]

Hi Imesh,

Please see inline.

On Tue, Oct 20, 2015 at 11:08 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>>
>>
>> I think the proper way to secure the Jaggery services is by using SSO.
>>
>
> I tend to disagree on this statement. SSO is used when authenticating a
> human to a series of software systems. An API should not use SSO for
> authentication rather it should use session based authentication either by
> creating session tokens or API Keys, refer this [3].
>

SSO can be used to authenticate the user who is accessing the
monitoring/metering dashboard, thereby authenticating him to the API as
well. We don't need to maintain a session token/cookie for this which is an
overhead for this scenario, IMO.


>
>
>> According to the thread on wso2dev@ with subject "SingleSignOn support
>> in DAS Analytics Dashboard" this is not yet supported in DAS. The approach
>> taken in analytics.jsg as you mentioned require a separate login screen as
>> in [1]. IMHO, this is not a suitable method to secure a Jaggery based API.
>>
>> No, have a look at the analytics.jag authentication logic. It first
> accepts an Authorization header and creates a session token. Authorization
> header can accept basic auth, see [4]. Afterwards corresponding calls are
> authenticated using authToken/JSESSIONID.
>

If we are using basic auth, the user needs to submit the credentials via a
form, which is again an overhead. Any implementation of
authToken/JSESSIONID would require the user to submit credential at some
layer. What I'm suggesting is to authenticate the user via SSO to the DAS
dashboard, which would authenticate him to the API as well. I'm -1 on
developing a separate login screen for this.


>
>
>> Regarding table names in SQL queries; this is not the best approach to
>> design the API but these table names are escaped from request parameters
>> [2] which would minimize the risk of a SQL injection attack. This is
>> definitely a potential security issue as well as an API design issue we
>> need to fix. But I think fixing this will need a major refactoring to the
>> Jaggery files. wdyt?
>>
>
> No, we can simply fix this by creating an API per table/entity.
>

This would not be manageable as we add entities in future I think. We can
handle this internally by not using the request parameter variable to
create the query. But rather choose the correct sql query conditionally
based on the request parameter. This would basically result in rewriting
all Jaggery files.

Thanks.



>
>> [1]
>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag
>> [2]
>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26
>>
>> [3] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
> [4]
> https://github.com/wso2/carbon-analytics/blob/d7d4f7c31981eb6aff8921fefba7c030eb11a80a/components/analytics-io/org.wso2.carbon.analytics.jsservice/src/main/java/org/wso2/carbon/analytics/jsservice/Utils.java#L352
>
> Thanks
>
> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> I think the proper way to secure the Jaggery services is by using SSO.
>> According to the thread on wso2dev@ with subject "SingleSignOn support
>> in DAS Analytics Dashboard" this is not yet supported in DAS. The approach
>> taken in analytics.jsg as you mentioned require a separate login screen as
>> in [1]. IMHO, this is not a suitable method to secure a Jaggery based API.
>>
>> Regarding table names in SQL queries; this is not the best approach to
>> design the API but these table names are escaped from request parameters
>> [2] which would minimize the risk of a SQL injection attack. This is
>> definitely a potential security issue as well as an API design issue we
>> need to fix. But I think fixing this will need a major refactoring to the
>> Jaggery files. wdyt?
>>
>> [1]
>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag
>> [2]
>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26
>>
>> Thanks.
>>
>> On Tue, Oct 20, 2015 at 8:38 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> It looks like there are two security issues in the APIs exposed by the
>>> DAS metering and monitoring dashboards [1], [2]:
>>>
>>>- 

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC1

[Akila Ravihansa Perera]

Hi Gayan,

The code reference you pointed at [1] is used in a prepared SQL statement
[2]. The risk of SQL injection attack is minimal in that case, AFAIU.

[1]
https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L49
[2]
https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L53

Thanks.

On Tue, Oct 20, 2015 at 11:33 PM, Akila Ravihansa Perera <raviha...@wso2.com
> wrote:

> Hi Imesh,
>
> Please see inline.
>
> On Tue, Oct 20, 2015 at 11:08 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>>
>>>
>>> I think the proper way to secure the Jaggery services is by using SSO.
>>>
>>
>> I tend to disagree on this statement. SSO is used when authenticating a
>> human to a series of software systems. An API should not use SSO for
>> authentication rather it should use session based authentication either by
>> creating session tokens or API Keys, refer this [3].
>>
>
> SSO can be used to authenticate the user who is accessing the
> monitoring/metering dashboard, thereby authenticating him to the API as
> well. We don't need to maintain a session token/cookie for this which is an
> overhead for this scenario, IMO.
>
>
>>
>>
>>> According to the thread on wso2dev@ with subject "SingleSignOn support
>>> in DAS Analytics Dashboard" this is not yet supported in DAS. The approach
>>> taken in analytics.jsg as you mentioned require a separate login screen as
>>> in [1]. IMHO, this is not a suitable method to secure a Jaggery based API.
>>>
>>> No, have a look at the analytics.jag authentication logic. It first
>> accepts an Authorization header and creates a session token. Authorization
>> header can accept basic auth, see [4]. Afterwards corresponding calls are
>> authenticated using authToken/JSESSIONID.
>>
>
> If we are using basic auth, the user needs to submit the credentials via a
> form, which is again an overhead. Any implementation of
> authToken/JSESSIONID would require the user to submit credential at some
> layer. What I'm suggesting is to authenticate the user via SSO to the DAS
> dashboard, which would authenticate him to the API as well. I'm -1 on
> developing a separate login screen for this.
>
>
>>
>>
>>> Regarding table names in SQL queries; this is not the best approach to
>>> design the API but these table names are escaped from request parameters
>>> [2] which would minimize the risk of a SQL injection attack. This is
>>> definitely a potential security issue as well as an API design issue we
>>> need to fix. But I think fixing this will need a major refactoring to the
>>> Jaggery files. wdyt?
>>>
>>
>> No, we can simply fix this by creating an API per table/entity.
>>
>
> This would not be manageable as we add entities in future I think. We can
> handle this internally by not using the request parameter variable to
> create the query. But rather choose the correct sql query conditionally
> based on the request parameter. This would basically result in rewriting
> all Jaggery files.
>
> Thanks.
>
>
>
>>
>>> [1]
>>> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag
>>> [2]
>>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26
>>>
>>> [3] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
>> [4]
>> https://github.com/wso2/carbon-analytics/blob/d7d4f7c31981eb6aff8921fefba7c030eb11a80a/components/analytics-io/org.wso2.carbon.analytics.jsservice/src/main/java/org/wso2/carbon/analytics/jsservice/Utils.java#L352
>>
>> Thanks
>>
>> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Imesh,
>>>
>>> I think the proper way to secure the Jaggery services is by using SSO.
>>> According to the thread on wso2dev@ with subject "SingleSignOn support
>>> in DAS Analytics Dashboard" this is not yet supported in DAS. The approach
>>> taken in analytics.jsg as you mentioned require a separate login screen as
>>> in [1]. IMHO, this is not a suitable method to secure a Jaggery based API.
>>>
>>> Regarding table names in SQL queries; this is not the best approach to
>>> design the API but these tab

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC1

[Akila Ravihansa Perera]

Hi Imesh,

Please see inline. Sorry to drag this, but I think it's better to clarify
unclear areas :)

SSO can be used to authenticate the user who is accessing the
>> monitoring/metering dashboard, thereby authenticating him to the API as
>> well. We don't need to maintain a session token/cookie for this which is an
>> overhead for this scenario, IMO.
>>
>>
> Yes that's true but in a such design any other external system will not be
> able to to access the APIs using API Keys without having to integrate with
> the same SSO solution.
>

I tend to disagree. Using a compatible Identity Provider (for eg: WSO2 IS)
we can secure the API using multiple grant types. In this scenario API can
be secured via SSO but not limited to that.


> Imagine Twitter has exposed set of APIs using Twitter SSO solution. Now if
> we were to consume those APIs in a X system. This X system needs to
> integrate with Twitter SSO solution first. IMO this is not a good design,
> ideally those APIs should be accessible with API Keys. This is how actually
> Twitter has exposed their APIs.
>
>>
>>>
>> If we are using basic auth, the user needs to submit the credentials via
>> a form, which is again an overhead. Any implementation of
>> authToken/JSESSIONID would require the user to submit credential at some
>> layer. What I'm suggesting is to authenticate the user via SSO to the DAS
>> dashboard, which would authenticate him to the API as well. I'm -1 on
>> developing a separate login screen for this.
>>
>>
> May be this was not clear. We do not need a login page to make a request
> to an API endpoint which is secured with Basic Auth. We can make a HTTP
> call with an Authorization header having credentials (Base64 encoded) via
> HTTPS.
>

If we are going to send the Authorization header then we need to get the
credentials from the user first. I'm not clear how you plan to implement
this without a login screen. How do you propose to create this header in
client request?


>
>>>
>> This would not be manageable as we add entities in future I think. We can
>> handle this internally by not using the request parameter variable to
>> create the query. But rather choose the correct sql query conditionally
>> based on the request parameter. This would basically result in rewriting
>> all Jaggery files.
>>
>


>
> Yes ideally it should be the context path (/api/member -> member table,
> /api/cluster/health -> cluster health table, etc)
>

+1



>
> Thanks
>
> On Tue, Oct 20, 2015 at 11:40 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Gayan,
>>
>> The code reference you pointed at [1] is used in a prepared SQL statement
>> [2]. The risk of SQL injection attack is minimal in that case, AFAIU.
>>
>> [1]
>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L49
>> [2]
>> https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L53
>>
>> Thanks.
>>
>> On Tue, Oct 20, 2015 at 11:33 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Imesh,
>>>
>>> Please see inline.
>>>
>>> On Tue, Oct 20, 2015 at 11:08 PM, Imesh Gunaratne <im...@wso2.com>
>>> wrote:
>>>
>>>> On Tue, Oct 20, 2015 at 10:25 PM, Akila Ravihansa Perera <
>>>> raviha...@wso2.com> wrote:
>>>>>
>>>>>
>>>>> I think the proper way to secure the Jaggery services is by using SSO.
>>>>>
>>>>
>>>> I tend to disagree on this statement. SSO is used when authenticating a
>>>> human to a series of software systems. An API should not use SSO for
>>>> authentication rather it should use session based authentication either by
>>>> creating session tokens or API Keys, refer this [3].
>>>>
>>>
>>> SSO can be used to authenticate the user who is accessing the
>>> monitoring/metering dashboard, thereby authenticating him to the API as
>>> well. We don't need to maintain a session token/cookie for this which is an
>>> overhead for this scenario, IMO.
>>>
>>>
>>>>
>>>>
>>>>> According to the thread on wso2dev@ with subject "SingleSignOn
>>>>> support in DAS Analytics Dashboard" this is not yet supported in DAS. The
>>>>> approach taken in analytics.jsg as you mentioned require a separate login
>>>>> screen a

Re: [Dev] [VOTE] Release WSO2 Private PaaS 4.1.0 RC1

[Akila Ravihansa Perera]

Hi Imesh,

I think the proper way to secure the Jaggery services is by using SSO.
According to the thread on wso2dev@ with subject "SingleSignOn support in
DAS Analytics Dashboard" this is not yet supported in DAS. The approach
taken in analytics.jsg as you mentioned require a separate login screen as
in [1]. IMHO, this is not a suitable method to secure a Jaggery based API.

Regarding table names in SQL queries; this is not the best approach to
design the API but these table names are escaped from request parameters
[2] which would minimize the risk of a SQL injection attack. This is
definitely a potential security issue as well as an API design issue we
need to fix. But I think fixing this will need a major refactoring to the
Jaggery files. wdyt?

[1]
https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/theme/templates/login.jag
[2]
https://github.com/wso2/product-private-paas/blob/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files/member-info.jag#L26

Thanks.

On Tue, Oct 20, 2015 at 8:38 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> Hi,
>
> It looks like there are two security issues in the APIs exposed by the DAS
> metering and monitoring dashboards [1], [2]:
>
>- APIs have no authentication mechanism
>- Table name is concatenated in the SQL queries
>
> We may need to add an authentication check similar to analytics.jag [3]:
>
> var authParam = request.getHeader(AUTHORIZATION_HEADER);
> if (authParam != null) {
> credentials = JSUtils.authenticate(authParam);
> authenticationAdminStub = new
> AuthenticationAdminStub(authenticationWSUrl);
> authenticationAdminStub.login(credentials[0], credentials[1],
> LOCALHOST);
> var serviceContext =
> authenticationAdminStub._getServiceClient().getLastOperationContext()
> .getServiceContext();
> var sessionCookie =
> serviceContext.getProperty(HTTPConstants.COOKIE_STRING);
> options.setProperty(HTTPConstants.COOKIE_STRING, sessionCookie);
> } else {
> var token = session.get(AUTH_TOKEN);
> if (token != null) {
> options.setProperty(HTTPConstants.COOKIE_STRING, token);
> } else {
> log.error("user is not authenticated!");
> response.status = HTTP_USER_NOT_AUTHENTICATED;
> print('{ "status": "Failed", "message": "User is not
> authenticated." }');
> return;
> }
> }
>
> In addition we may need to avoid concatenating table names in SQL queries.
>
> [1]
> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1/extensions/das/artifacts/metering-dashboard/jaggery-files
> [2]
> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1/extensions/das/artifacts/monitoring-dashboard/jaggery-files
> [3]
> https://github.com/wso2/carbon-dashboards/blob/master/apps/portal/controllers/apis/analytics.jag#L88
>
> I think we may need to cancel this vote and do RC2 by fixing these
> problems.
>
> Thanks
>
> On Tue, Oct 20, 2015 at 5:02 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> This is the first release candidate of WSO2 Private PaaS 4.1.0.
>>
>> This release fixes the following issues:
>> https://wso2.org/jira/issues/?filter=12464
>>
>> Please download, test and vote. The vote will be open for 72 hours or as
>> needed.
>>
>> *​Source and binary distribution files:*
>> https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-rc1
>>
>> *Maven staging repository:*
>> http://maven.wso2.org/nexus/content/repositories/orgwso2ppaas-027/
>>
>> *The tag to be voted upon:*
>> https://github.com/wso2/product-private-paas/tree/v4.1.0-rc1
>>
>>
>> [ ] Broken - do not release (explain why)
>> [ ] Stable - go ahead and release
>>
>>
>> Thanks,
>> The WSO2 Private PaaS Team
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>


-- 
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

Re: [Dev] Start servers with public ip on ec2 instance

[Akila Ravihansa Perera]

Hi Anuruddha,

You need to set bind-address parameter in your transport receivers in
axis2.xml as follows;

hostname or IP
address

Read [1] for more info.

[1] https://docs.wso2.com/display/ESB481/Setting+Up+Host+Names+and+Ports

Thanks.

On Sat, Oct 17, 2015 at 10:46 AM, Nadeesha Gamage <nadee...@wso2.com> wrote:

> Hi Anuruddha,
> Please try the instruction in the following article
>
> http://wso2.com/library/knowledge-base/2011/01/custom-urls-wso2-esb-proxy-services/
>
>
> Thank you,
> Nadeesha
>
> On Fri, Oct 16, 2015 at 10:04 PM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> Hi Devs,
>>
>> I am trying start a wso2esb in ec2 instance. But the server is starting
>> with private ip instead of public IP.
>>
>> How can I set the public ip to server when it is starting up.
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> a <thili...@wso2.com>nurudd...@wso2.com
>>
>
>
>
> --
> Nadeesha Gamage
> Associate Technical Lead - Solutions Engineering
> T : +94 77 394 5706
> B : https://nadeesha678.wordpress.com/
>



-- 
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

[Dev] WSO2 Private PaaS Cartridges v4.1.0 released

[Akila Ravihansa Perera]

Hi,

The WSO2 Private PaaS community is pleased to announce the release of the
WSO2 Private PaaS Cartridges 4.1.0. This release includes cartridges for
the following WSO2 products.

 - WSO2 API Manager 1.9.0
 - WSO2 API Manager 1.9.1
 - WSO2 Enterprise Service Bus 4.8.1
 - WSO2 Identity Server 5.0.0
 - WSO2 Application Server 5.2.1

The following tools are shipped with this release.

 - WSO2 Private PaaS Configurator 4.1.0
   This pure Python based tool can be used to apply templates written using
Jinja template language.

 - WSO2 VM Tools 4.1.0
   This distribution contains wso2installer Puppet module which is a
generic module to deploy any WSO2 cartridge. It also contains init scripts for
supported cloud infrastructure platforms, which are used to bootstrap
cartridge instances. Please refer to README file in the distribution for
instructions.


*Docker images for WSO2 products*

We are pleased to announce the availability of Docker images for the
following WSO2 products. Docker images can be pulled from DockerHub. These
Docker images can be used for a stand-alone deployment or on top of WSO2
Private PaaS.

 - WSO2 API Manager ver. 1.9.0, 1.9.1  [1]
 - WSO2 Enterprise Service Bus ver. 4.8.1 [2]
 - WSO2 Identity Server ver. 5.0.0 [3]
 - WSO2 Application Server ver. 5.2.1 [4]


Please note that above cartridges and Docker images are compatible with
WSO2 Private PaaS 4.1.0-beta or higher releases. However, you may use
Docker images in a stand-alone deployment without WSO2 Private PaaS.

Your feedback is most welcome. The distributions are available at [5]. Any
issues can be reported in [6].

[1] https://hub.docker.com/r/wso2/am/
[2] https://hub.docker.com/r/wso2/esb/
[3] https://hub.docker.com/r/wso2/is/
[4] https://hub.docker.com/r/wso2/as/
[5]
https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-cartridges-4.1.0/
[6] https://wso2.org/jira/browse/PPC

-- 
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

[Dev] Pass build-time arguments when building Docker images for PPaaS cartridges

[Akila Ravihansa Perera]

Hi,

Currently PCA_VERSION and PPAAS_VERSION parameters are hard-coded in
Dockerfiles of cartridge images hence these files need to be updated for
each release manually. I'm proposing to use build-time variables when
building the Docker images to resolve this. Fortunately, Docker has
introduced this feature in their master branch few days ago [1]. Hopefully
this feature will be available in the next Docker release.

[1] https://github.com/docker/docker/pull/15182

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

Re: [Dev] [PPaaS] private-paas-cartridges repository structure

[Akila Ravihansa Perera]

Hi,

We are planning to create a single set of templates for samples using Jinja
templating language. Once it is done we can remove individual sample
artifacts.

Thanks.

On Wednesday, 7 October 2015, Imesh Gunaratne <im...@wso2.com> wrote:

> On Wed, Oct 7, 2015 at 2:08 AM, Lasindu Charith <lasi...@wso2.com
> <javascript:_e(%7B%7D,'cvml','lasi...@wso2.com');>> wrote:
>
>> Hi Akila/Imesh,
>>
>> Any reason why we moved common samples (network partitions, autoscale
>> policies, deployment policies, application policies) inside each cartridge?
>>
>> If those artifacts are similar, what if we keep them in a common place?
>> (say inside common/samples/..).
>>
>
> +1 A good suggestion! Yes we could move above artifacts to common/samples
> folder. However when we are creating the cartridge distribution we may need
> to copy them to the cartridge/samples folder similar to common/plugins.
>
> Thanks
>
> On Wed, Oct 7, 2015 at 2:50 AM, Rajkumar Rajaratnam <rajkum...@wso2.com
> <javascript:_e(%7B%7D,'cvml','rajkum...@wso2.com');>> wrote:
>
>>
>>
>> On Wed, Oct 7, 2015 at 9:38 AM, Lasindu Charith <lasi...@wso2.com
>> <javascript:_e(%7B%7D,'cvml','lasi...@wso2.com');>> wrote:
>>
>>> Hi Akila/Imesh,
>>>
>>> Any reason why we moved common samples (network partitions, autoscale
>>> policies, deployment policies, application policies) inside each cartridge?
>>>
>>> If those artifacts are similar, what if we keep them in a common place?
>>> (say inside common/samples/..). Once we introduce more cartridges, we will
>>> have to add them again and if there's a new change we'll have to change it
>>> everywhere(maintainability?)
>>>
>>
>> ​+1 to keep them in a common place. Why we are duplicating these common
>> artifacts across all the cartridges?
>> ​
>>
>>
>>>
>>> WDYT?
>>> If the priority/concern was regarding modularity, this approach is
>>> totally fine for me.
>>>
>>> Thanks,
>>>
>>> On Sun, Oct 4, 2015 at 1:33 PM, Imesh Gunaratne <im...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','im...@wso2.com');>> wrote:
>>>
>>>> It looks good Akila!
>>>>
>>>> On Mon, Oct 5, 2015 at 12:01 AM, Akila Ravihansa Perera <
>>>> raviha...@wso2.com <javascript:_e(%7B%7D,'cvml','raviha...@wso2.com');>
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've restructured the repo considering what we discussed here. I've
>>>>> also added a distribution for VM related files.
>>>>>
>>>>> Final directory structure as follows;
>>>>>
>>>>> ├── common
>>>>> │   ├── configurator
>>>>> │   │   ├── live-test
>>>>> │   │   │   ├── src
>>>>> │   │   ├── src
>>>>> │   │   │   ├── assembly
>>>>> │   │   │   └── main
>>>>> │   ├── docker
>>>>> │   │   ├── base-image
>>>>> │   │   │   ├── packages
>>>>> │   │   │   └── scripts
>>>>> │   │   └── scripts
>>>>> │   ├── plugins
>>>>> │   └── vm
>>>>> │   ├── assembly
>>>>> │   ├── init-scripts
>>>>> │   │   ├── ec2
>>>>> │   │   ├── gce
>>>>> │   │   ├── openstack
>>>>> │   │   └── vcloud
>>>>> │   ├── puppet
>>>>> │   │   ├── manifests
>>>>> │   │   └── modules
>>>>> ├── wso2am
>>>>> │   ├── 1.9.0
>>>>> │   │   ├── assembly
>>>>> │   │   ├── docker
>>>>> │   │   │   ├── packages
>>>>> │   │   │   ├── plugins
>>>>> │   │   │   └── scripts
>>>>> │   │   ├── plugins
>>>>> │   │   ├── samples
>>>>> │   │   │   ├── application-policies
>>>>> │   │   │   ├── applications
>>>>> │   │   │   ├── autoscaling-policies
>>>>> │   │   │   ├── cartridge-groups
>>>>> │   │   │   ├── cartridges
>>>>> │   │   │   ├── deployment-policies
>>>>> │   │   │   ├── kubernetes-clusters
>>>>> │   │   │   ├── network-partitions
>>>>> │   │   │   └── template-modules
>>>>> │   │   └── template-module
>>>>> │   │   ├── files
>>>>> │   │   ├── src
>>>>> │   │   └── templat

[Dev] WSO2 PPaaS v4.1.0-BETA released

[Akila Ravihansa Perera]

Hi,

The WSO2 Private PaaS community is pleased to announce the release of the
WSO2 Private PaaS 4.1.0-BETA. This release includes following bug-fixes,
improvements and features.

Bug

   - [PAAS-213 <https://wso2.org/jira/browse/PAAS-213>] - Autoscaling is
   not working in super-tenant if an artifact repo is given
   - [PAAS-226 <https://wso2.org/jira/browse/PAAS-226>] - Application Sign
   Up is Enabled before Activating the Application
   - [PAAS-229 <https://wso2.org/jira/browse/PAAS-229>] - Tenant can
   un-deploy a multi tenant application
   - [PAAS-230 <https://wso2.org/jira/browse/PAAS-230>] - Cannot Unsign up
   from Management Console UI
   - [PAAS-233 <https://wso2.org/jira/browse/PAAS-233>] - PCA git repo
   artifact delete does not delete the artifact from git
   - [PAAS-234 <https://wso2.org/jira/browse/PAAS-234>] - PPaaS 4.1.0
   Carbon UI has Stratos branding
   - [PAAS-235 <https://wso2.org/jira/browse/PAAS-235>] - Application name
   cannot have lengthy strings

Improvement

   - [PAAS-240 <https://wso2.org/jira/browse/PAAS-240>] - Copy template
   module dependencies during the build
   - [PAAS-242 <https://wso2.org/jira/browse/PAAS-242>] - Create common
   puppet module to wso2 products
   - [PAAS-244 <https://wso2.org/jira/browse/PAAS-244>] - Gracefully
   Shutting Down Servers
   - [PAAS-248 <https://wso2.org/jira/browse/PAAS-248>] - Update Apache
   Stratos Features to version 4.1.3


Known Issues

   - [PAAS-246 <https://wso2.org/jira/browse/PAAS-246>] - Handle
   Configurator errors in the plugin and hold further execution
   - [PAAS-232 <https://wso2.org/jira/browse/PAAS-232>] - Artifact git repo
   password cannot have @ sign
   - [PAAS-231 <https://wso2.org/jira/browse/PAAS-231>] - Remove sign up
   does not completely remove all the artifacts



Your feedback is most welcome. The distribution is available at [1]. Any
issues can be reported in [2].

[1] https://svn.wso2.org/repos/wso2/scratch/PPAAS/wso2ppaas-4.1.0-BETA
[2] https://wso2.org/jira/browse/PAAS

-- 
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

Re: [Dev] [PPaaS] private-paas-cartridges repository structure

[Akila Ravihansa Perera]

ayan Gunarathne <gay...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 1, 2015 at 6:06 PM, Reka Thirunavukkarasu <r...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Shall we maintain an installer as well(specially for VM cartridges) in
>>>>> this repository to quickly create specific cartridges in puppet? What this
>>>>> installer could do is,
>>>>>
>>>>> User has to provide the packs and set of values for the environment
>>>>> variables.
>>>>>
>>>>> - Install puppet master
>>>>> - Locate the relevant cartridges puppet modules
>>>>> - Place the packs, template modules and plugins to right location
>>>>> - Export all the user given environment variables
>>>>> - Execute configurator to configure the samples
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> Good thought reka. As our offline chat , we can plan to have two
>>>> installers for ppaas and ppaas cartridges.We can have the ppaas installer
>>>> to set up the ppaas related stuff while ppaas cartridge installer to set up
>>>> the cartridge specific installations.
>>>>
>>> +1. We can check whether we can modify the stratos-installer and use it
>>> as a ppaas-installer rather writing it from the scratch.
>>>
>>> Thanks,
>>> Reka
>>>
>>>>
>>>>> Thanks,
>>>>> Reka
>>>>>
>>>>> On Thu, Oct 1, 2015 at 2:01 PM, Gayan Gunarathne <gay...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Akila,
>>>>>>
>>>>>> Common folder has all the common stuff related to the cartridges.So
>>>>>> if someone can navigate to the common folder and get the stuff shared 
>>>>>> among
>>>>>> the cartridges.
>>>>>>
>>>>>> I think it is meaningful to have those common stuff at a one place,
>>>>>> then someone new to this repository also have a feeling those stuff will 
>>>>>> be
>>>>>> common for all the cartridges.Common PCA plugins and utils also we can 
>>>>>> have
>>>>>> inside the common folder
>>>>>>
>>>>>> Thanks,
>>>>>> Gayan
>>>>>>
>>>>>> On Thu, Oct 1, 2015 at 12:52 PM, Akila Ravihansa Perera <
>>>>>> raviha...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Gayan,
>>>>>>>
>>>>>>> Wouldn't it be easier to navigate if we move those common folders to
>>>>>>> root folder?
>>>>>>>
>>>>>>> We can create a common folder under /plugins/ folder to keep common
>>>>>>> PCA plugins and util files.
>>>>>>>
>>>>>>> Just a thought...wdyt?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Thu, Oct 1, 2015 at 10:29 AM, Gayan Gunarathne <gay...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Adding to the Dev list
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 1, 2015 at 7:05 AM, Imesh Gunaratne <im...@wso2.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Shall we move this discussion to Dev?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On Wed, Sep 30, 2015 at 11:02 PM, Gayan Gunarathne <
>>>>>>>>> gay...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> As puppet,init-scripts,base image are common for all the
>>>>>>>>>> cartridges,shall we group them under common?
>>>>>>>>>> Also what about the configurator?I can see two options
>>>>>>>>>> One option will be move the configurator to the private-paas
>>>>>>>>>> repository and release it with the private paas.Other option will be 
>>>>>>>>>> we can
>>>>>>>>>> do the separate release for the configurator.Seems it is better to 
>&g

Re: [Dev] [PPaaS] private-paas-cartridges repository structure

[Akila Ravihansa Perera]

>
>
>
> Shall we maintain an installer as well(specially for VM cartridges) in
> this repository to quickly create specific cartridges in puppet? What this
> installer could do is,
>
> User has to provide the packs and set of values for the environment
> variables.
>
> - Install puppet master
> - Locate the relevant cartridges puppet modules
> - Place the packs, template modules and plugins to right location
> - Export all the user given environment variables
> - Execute configurator to configure the samples
>
> WDYT?
>
> Thanks,
> Reka
>


Big +1

I'm looking into creating a single set of templates using Jinja template
language to cater for all IaaS requirements. We can maintain separate set
of module.ini files to create artifacts for different IaaS's. This we can
reduce the complexity in current sample folder structure.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [PPaaS] private-paas-cartridges repository structure

[Akila Ravihansa Perera]

Hi Gayan,

Wouldn't it be easier to navigate if we move those common folders to root
folder?

We can create a common folder under /plugins/ folder to keep common PCA
plugins and util files.

Just a thought...wdyt?

Thanks.

On Thu, Oct 1, 2015 at 10:29 AM, Gayan Gunarathne <gay...@wso2.com> wrote:

> Adding to the Dev list
>
>
> On Thu, Oct 1, 2015 at 7:05 AM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>> Shall we move this discussion to Dev?
>>
>> Thanks
>>
>> On Wed, Sep 30, 2015 at 11:02 PM, Gayan Gunarathne <gay...@wso2.com>
>> wrote:
>>
>>> As puppet,init-scripts,base image are common for all the
>>> cartridges,shall we group them under common?
>>> Also what about the configurator?I can see two options
>>> One option will be move the configurator to the private-paas repository
>>> and release it with the private paas.Other option will be we can do the
>>> separate release for the configurator.Seems it is better to have a separate
>>> release for the configurator. WDYT?
>>>
>>> Thanks,
>>> Gayan
>>>
>>> On Wed, Sep 30, 2015 at 10:44 PM, Gayan Gunarathne <gay...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Sep 30, 2015 at 9:48 PM, Akila Ravihansa Perera <
>>>> raviha...@wso2.com> wrote:
>>>>
>>>>> +1 for having a simple folder structure. I think we can move the
>>>>> contents in /common/ folder to root folder. One can easily identify the
>>>>> important files available and easy to navigate as well.
>>>>>
>>>>> What should be the Maven groupId for this repo? How about
>>>>> "org.wso2.ppaas.cartridges" or "org.wso2.cartridges" ?
>>>>>
>>>> We can use org.wso2.ppaas.cartridges as groupId
>>>>
>>>> Thanks,
>>>> Gayan
>>>>
>>>>
>>>>>
>>>>
>>>>> On Wed, Sep 30, 2015 at 9:24 PM, Imesh Gunaratne <im...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>  I would like to reduce the complexity of the folder structure and
>>>>>> make it much simple. Shall we have some thing like below:
>>>>>>
>>>>>> private-paas-cartridges/
>>>>>> |--/common/
>>>>>>|--/configurator/
>>>>>>|--/puppet/
>>>>>>   |--/wso2-installer/
>>>>>>|--/scripts/
>>>>>>   |---/ec2/init.sh
>>>>>>   |---/openstack/init.sh
>>>>>>
>>>>>> |--/wso2esb/4.9.0/
>>>>>>|-/template-module/
>>>>>>|-/cartridge-agent-plugins/
>>>>>>|-/application/
>>>>>>|-/docker/
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Wed, Sep 30, 2015 at 9:13 PM, Imesh Gunaratne <im...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> May be we can have this discussion in Dev, I cannot see any reason
>>>>>>> to take this private.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On Wed, Sep 30, 2015 at 6:26 PM, Gayan Gunarathne <gay...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Adding Engineering group
>>>>>>>>
>>>>>>>>
>>>>>>>> -- Forwarded message --
>>>>>>>> From: Gayan Gunarathne <gay...@wso2.com>
>>>>>>>> Date: Wed, Sep 30, 2015 at 6:26 PM
>>>>>>>> Subject: [PPaaS] private-paas-cartridges repository structure
>>>>>>>> To: Imesh Gunaratne <im...@wso2.com>, Reka Thirunavukkarasu <
>>>>>>>> r...@wso2.com>, Udara Liyanage <ud...@wso2.com>, Lahiru Sandaruwan
>>>>>>>> <lahi...@wso2.com>, Rajkumar Rajaratnam <rajkum...@wso2.com>,
>>>>>>>> Sajith Kariyawasam <saj...@wso2.com>, Isuru Haththotuwa <
>>>>>>>> isu

Re: [Dev] WSO2 Carbon Common Puppet Module

[Akila Ravihansa Perera]

Hi Imesh,

Since this module is not really being used by other modules rather it is
the only Puppet module that exists for PPaaS; shall we give it a generic
name? wso2carbon could be confusing with our Carbon product.

For eg: ppaas_deployer

wdyt?

Thanks.

On Tue, Sep 22, 2015 at 3:15 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> Hi Anuruddha,
>
> IMO it would be better to call $subject wso2carbon instead of wso2servers:
>
> https://github.com/wso2/product-private-paas/tree/master/cartridges/vm/puppet/modules/wso2servers
>
> Thanks
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] WSO2 Carbon Common Puppet Module

[Akila Ravihansa Perera]

Hi Gayan,

I don't see the relevance to name a Puppet module wso2carbon because all
products are based on Carbon. All I'm saying is this could be confusing to
an end user since we have a separate product called wso2carbon. I was only
giving a suggestion, we can rename it to something like "wso2_installer".
Does it make more sense?

Thanks.

On Tue, Sep 22, 2015 at 3:42 PM, Gayan Gunarathne <gay...@wso2.com> wrote:

> That puppet modules contains the products based on the WSO2 carbon. I
> think it is OK to name as wso2carbon or wso2servers. If we use the
> ppaas_deployer , it may reflect the meaning that all the deploying
> artifacts are within that folder.
>
> Thanks,
> Gayan
>
> On Tue, Sep 22, 2015 at 3:31 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> Since this module is not really being used by other modules rather it is
>> the only Puppet module that exists for PPaaS; shall we give it a generic
>> name? wso2carbon could be confusing with our Carbon product.
>>
>> For eg: ppaas_deployer
>>
>> wdyt?
>>
>> Thanks.
>>
>> On Tue, Sep 22, 2015 at 3:15 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>> Hi Anuruddha,
>>>
>>> IMO it would be better to call $subject wso2carbon instead of
>>> wso2servers:
>>>
>>> https://github.com/wso2/product-private-paas/tree/master/cartridges/vm/puppet/modules/wso2servers
>>>
>>> Thanks
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Senior Technical Lead
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: http://imesh.gunaratne.org
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead, WSO2 Inc. (http://wso2.com)
> Committer & PMC Member, Apache Stratos
> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>
>
>



-- 
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

Re: [Dev] [CEP 3.1.0] Syncing failed when becoming a Passive Node for tenant

[Akila Ravihansa Perera]

gt;>>> at
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
>>>>>>>> at
>>>>>>>> org.wso2.carbon.core.init.CarbonServerManager.initializeCarbon(CarbonServerManager.java:517)
>>>>>>>> at
>>>>>>>> org.wso2.carbon.core.init.CarbonServerManager.start(CarbonServerManager.java:219)
>>>>>>>> at
>>>>>>>> org.wso2.carbon.core.internal.CarbonCoreServiceComponent.activate(CarbonCoreServiceComponent.java:77)
>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>> at
>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>>>>>> at
>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:146)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:347)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:197)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:343)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
>>>>>>>> at
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.http.servlet.internal.Activator.registerHttpService(Activator.java:81)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.http.servlet.internal.Activator.addProxyServlet(Activator.java:60)
>>>>>>>> at
>>>>>>>> org.eclipse.equinox.http.servlet.internal.ProxyServlet.init(ProxyServlet.java:40)
>>>>>>>> at
>>>>>>>> org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.init(DelegationServlet.java:38)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1267)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1186)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1081)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5027)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5314)
>>>>>>>> at
>>>>>>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
>>>>>>>> at
>>>>>>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
>>>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://docs.wso2.com/display/CLUSTER420/Clustering+CEP+3.0.0+and+3.1.0#ClusteringCEP3.0.0and3.1.0-HAdeployment(recommended)
>>>>>>>> [2]
>>>>>>>> https://drive.google.com/a/wso2.com/file/d/0Bw0NgSFZG5YkQk4zQndLMnc0OFE/view?usp=sharing
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Thanks and Regards,*
>>>>>>>> Anuruddha Lanka Liyanarachchi
>>>>>>>> Software Engineer - WSO2
>>>>>>>> Mobile : +94 (0) 712762611
>>>>>>>> Tel  : +94 112 145 345
>>>>>>>> a <thili...@wso2.com>nurudd...@wso2.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Ramindu De Silva*
>>>>>>> Software Engineer
>>>>>>> WSO2 Inc.: http://wso2.com
>>>>>>> lean.enterprise.middleware
>>>>>>>
>>>>>>> email: ramin...@wso2.com <sanj...@wso2.com>
>>>>>>> mob: +94 772339350
>>>>>>> mob: +94 782731766
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *S. Suhothayan*
>>>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor
>>>>>> *WSO2 Inc. *http://wso2.com
>>>>>> * <http://wso2.com/>*
>>>>>> lean . enterprise . middleware
>>>>>>
>>>>>>
>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>>>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter:
>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | 
>>>>>> linked-in:
>>>>>> http://lk.linkedin.com/in/suhothayan 
>>>>>> <http://lk.linkedin.com/in/suhothayan>*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Thanks and Regards,*
>>>>> Anuruddha Lanka Liyanarachchi
>>>>> Software Engineer - WSO2
>>>>> Mobile : +94 (0) 712762611
>>>>> Tel  : +94 112 145 345
>>>>> a <thili...@wso2.com>nurudd...@wso2.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *S. Suhothayan*
>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor
>>>> *WSO2 Inc. *http://wso2.com
>>>> * <http://wso2.com/>*
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter:
>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in:
>>>> http://lk.linkedin.com/in/suhothayan 
>>>> <http://lk.linkedin.com/in/suhothayan>*
>>>>
>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Senior Technical Lead
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: http://imesh.gunaratne.org
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Tishan Dahanayakage
>> Software Engineer
>> WSO2, Inc.
>> Mobile:+94 716481328
>>
>> Disclaimer: This communication may contain privileged or other
>> confidential information and is intended exclusively for the addressee/s.
>> If you are not the intended recipient/s, or believe that you may have
>> received this communication in error, please reply to the sender indicating
>> that fact and delete the copy you received and in addition, you should not
>> print, copy, re-transmit, disseminate, or otherwise use the information
>> contained in this communication. Internet communications cannot be
>> guaranteed to be timely, secure, error or virus-free. The sender does not
>> accept liability for any errors or omissions.
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a <thili...@wso2.com>nurudd...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] "svn: E200030: Index not exists: I_NODES_MOVED" error in CEP worker node

[Akila Ravihansa Perera]

.run(SvnOperationFactory.java:1235)
> at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
> at
> org.tmatesoft.svn.core.javahl17.SVNClientImpl.revert(SVNClientImpl.java:437)
> ... 13 more
> Caused by: org.tmatesoft.sqljet.core.SqlJetException: Index not exists:
> I_NODES_MOVED: error code is MISUSE
> at
> org.tmatesoft.sqljet.core.internal.table.SqlJetTable.checkIndexName(SqlJetTable.java:285)
> at
> org.tmatesoft.sqljet.core.internal.table.SqlJetTable.access$300(SqlJetTable.java:46)
> at
> org.tmatesoft.sqljet.core.internal.table.SqlJetTable$8.runWithLock(SqlJetTable.java:236)
> at
> org.tmatesoft.sqljet.core.table.SqlJetDb$1.runSynchronized(SqlJetDb.java:172)
> at
> org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
> at org.tmatesoft.sqljet.core.table.SqlJetDb.runWithLock(SqlJetDb.java:170)
> at
> org.tmatesoft.sqljet.core.internal.table.SqlJetTable.scope(SqlJetTable.java:233)
> at
> org.tmatesoft.sqljet.core.internal.table.SqlJetTable.scope(SqlJetTable.java:222)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetSelectStatement.openCursor(SVNSqlJetSelectStatement.java:59)
> ... 26 more
>
>
> Appreciate your suggestions to overcome this issue.
>
> Thanks,
> --
>
> *Sashika WijesingheSoftware Engineer - QA Team*
> Mobile : +94 (0) 774537487
> sash...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

Re: [Dev] Setting MVCC=TRUE causing null pointer issues in AppFactory - H2 DB

[Akila Ravihansa Perera]

yjs.scriptengine.engine.RhinoEngine.execScript(RhinoEngine.java:567)
> at org.jaggeryjs.scriptengine.engine.RhinoEngine.exec(RhinoEngine.java:273)
> at
> org.jaggeryjs.jaggery.core.manager.WebAppManager.execute(WebAppManager.java:541)
> at org.jaggeryjs.jaggery.core.JaggeryServlet.doGet(JaggeryServlet.java:24)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
> at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
> at
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
> at org.jaggeryjs.jaggery.core.JaggeryFilter.doFilter(JaggeryFilter.java:21)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47)
> at
> org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:56)
> at
> org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47)
> at
> org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:141)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:156)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:52)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at
> org.wso2.carbon.governance.api.generic.GenericArtifactManager.(GenericArtifactManager.java:89)
> at
> org.wso2.carbon.appfactory.core.governance.ApplicationManager.getAllApplicaitonsOfUser(ApplicationManager.java:110)
> at
> org.wso2.carbon.appfactory.application.mgt.service.ApplicationUserManagementService.getApplicaitonsOfTheUser(ApplicationUserManagementService.java:283)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
> ... 59 more
>  {module/application/get/list.jag}
>
>
> Thanks & Regards,
> S.A.Rajeevan
> Software Engineer WSO2 Inc
> E-Mail: rajeev...@wso2.com | Mobile : +94776411636
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
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

[Dev] WSO2 PPaaS v4.1.0-ALPHA released

[Akila Ravihansa Perera]

Hi,

The WSO2 Private PaaS community is pleased to announce the release of the
WSO2 Private PaaS 4.1.0-ALPHA. This release includes following bug-fixes,
improvements and features.

Known Issues

   - [PAAS-77 ] - Validated result of
   cartridge subscription should display on web console
   - [PAAS-83 ] - BAM metering
   dashboard error
   - [PAAS-87 ] - Load Balancer
   Rewrites Location Headers Irrespective of Location Header URL Host
   - [PAAS-88 ] - Multi-tenant
   cartridge doesn't clean up the GIT repository inside the Cartridge
   instances when unsubscribing
   - [PAAS-92 ] - Subscribed
   cartridge groups show all the subscribed cartridge informations instead of
   group's information
   - [PAAS-93 ] - CEP stat publisher
   have a hardcoded username and paasword
   - [PAAS-104 ] - PHP, Tomcat and
   MySQL cartridges are not working properly
   - [PAAS-107 ] - Filter logs in
   Centralized Log Viewer dashboard according to services
   - [PAAS-108 ] - http > https
   redirection does not work in Load Balancer
   - [PAAS-112 ] - BAM dashboard
   compilation error
   - [PAAS-123 ] - Private PaaS
   Metering Toolbox having hardcoded credentials
   - [PAAS-126 ] - Unable to trigger
   TenantCreatedEvent when the tenant is not there in TenantManager
   - [PAAS-148 ] - Production Setup
   - Stratos instances spawn exceeding max limit
   - [PAAS-152 ] - Stratos LB mix up
   members of different multi-tenant clusters in 10x10 concurrency
   - [PAAS-155 ] - Server is started
   twice in cartridge instance
   - [PAAS-158 ] - Instances are not
   getting removed from the topology
   - [PAAS-164 ] - Logs do not print
   any information if the activemq instances are down, while the stratos
   services are running
   - [PAAS-167 ] - CEP sends very
   large values for gradient and second derivative of load average
   - [PAAS-169 ] - Member
   termination flow retry in the case of the failure
   - [PAAS-176 ] - CEP went OOM
   after long running
   - [PAAS-179 ] - The Tomcat
   catridge deployed is having 0 running instances
   - [PAAS-198 ] - Cluster not
   scaling down - member stats contexts are not removed from AS when an
   obsolete member is getting timeout
   - [PAAS-199 ] - ReadyToShutdown
   Members are not getting removed from topology for a long time

Improvements

   - [PAAS-50 ] - Handle LB member
   termination event
   - [PAAS-168 ] - Calculate more
   accurate memory consumption and load average values
   - [PAAS-173 ] - Applying Secure
   Vault to passwords used in Cartridge Agent's stratos.sh file
   - [PAAS-185 ] - Support graceful
   shutdown for the cartridges when termination happens
   - [PAAS-202 ] - Refactor POM
   structure of product-private-paas

New Features

   - [PAAS-84 ] - Domain Mapping
   Improvements

Tasks

   - [PAAS-194 ] - Create IS VM
   Cartidge
   - [PAAS-216 ] - Create
   API-Manager 1.9.0 Cartridge
   - [PAAS-217 ] - Create Identity
   Server (IS) 5.0.0 Cartridge
   - [PAAS-220 ] - Create
   Application Server (AS) 5.2.1 Cartridge
   - [PAAS-236 ] - Upgrade
   automation framework engine version to 4.4.2

Sub-tasks

   - [PAAS-192 ] - Create ESB 4.8.1
   VM Cartridge
   - [PAAS-193 ] - Create AS 5.2.1
   VM Cartridge
   - [PAAS-203 ] - Create IS 5.0.0
   VM Cartridge
   - [PAAS-204 ] - Create API-M
   1.9.0 VM Cartridge
   - [PAAS-209 ] - Create ESB 4.8.1
   Docker Image
   - [PAAS-210 ] - Create AS 5.2.1
   Docker Image
   - [PAAS-211