Hi Isuru,

Thank you for the corrections. I will update you with the findings.

On Wed, Aug 3, 2016 at 10:17 AM, Isuru Haththotuwa <[email protected]> wrote:

> Hi Osura,
>
> Thanks for the notes.
>
> On Wed, Aug 3, 2016 at 10:09 AM, Osura Rathnayake <[email protected]>
> wrote:
>
>> Hi All,
>>
>> following are the meeting minutes of the hangout we had on 2nd of August,
>> 2016.
>>
>> We discussed about how to automate the deployment process and came to the
>> conclusion to use Azure Automation Script feature where you can generate a
>> script to automate the deployment of a particular resource. Output of this
>> can be in Azure Template( JSON), CLI, PowerShell, .NET or Ruby.
>> next task : 1) As the initial step, come up with templates and CLI
>> scripts for deployments of WSO2 AS, AM and ESB where there are a manager
>> node and two worker with hardcoded credentials and then use puppet. 2)
>> Research on the flow of automated deployment considering the dependencies.
>>
>> I was instructed to implement a method to get metering information
>> incurred on WSO2 products.
>>
> Correction: we need to check if Azure side supports the level of metering
> that is required. As per the information we have up to now, Azure has some
> billing information for the usage, in which we cannot drill down and get
> fine grained information.
>
>>
>> I was instructed to do the documentation on each automated deployment
>> template, in Github in markdown format.
>>
> From the R'n D point of view, lets prioritize the following:
>
>    1. automating the distributed deployment for few products (AS and
>    APIM, etc.)
>    2. Check the possibility of using WSO2 Puppet modules to create the VM.
>
>
>> Thank you,
>>
>> On Mon, Aug 1, 2016 at 12:44 PM, Imesh Gunaratne <[email protected]> wrote:
>>
>>> Hi Osura,
>>>
>>> It's good to see the blog posts!
>>> IMO it would be better if you can start writing documentation in
>>> parallel to blog posts, may be using Markdown format in Github.
>>>
>>> Thanks
>>>
>>> On Fri, Jul 29, 2016 at 10:49 AM, Osura Rathnayake <[email protected]>
>>> wrote:
>>>
>>>> Hi Isuru,
>>>>
>>>> I'm researching about automation in Azure. Shall we please have the
>>>> hangout on Monday?
>>>> BTW I will be able to complete the documentation on centralized
>>>> logging, monitoring, auto scaling and load balancing by this weekend and I
>>>> will update my blog with the progress. Your feedback is much appreciated.
>>>>
>>>> Thank you,
>>>>
>>>> On Fri, Jul 29, 2016 at 9:51 AM, Isuru Haththotuwa <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Osura,
>>>>>
>>>>> On Wed, Jul 27, 2016 at 9:17 AM, Osura Rathnayake <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Following are the meeting notes of the hangout we had on 25th of
>>>>>> July, 2016.
>>>>>>
>>>>>> *Centralized logging*
>>>>>>
>>>>>> Azure Log Analytics provides centralized logging which facilitates
>>>>>> the users to get logs from a given location in a VM, to a centralized
>>>>>> location so that they can analyse and query those logs as they need.
>>>>>> *next task - Documentation in terms of a blog post or webinar
>>>>>>
>>>>>> *Auto scaling*
>>>>>>
>>>>>> Auto scaling is achieved through scale sets in Azure. Scale set is a
>>>>>> set of VMs and auto scaling rules that defines auto scale metrics & 
>>>>>> actions
>>>>>> and the specification of the VMs.
>>>>>>
>>>>>> *Limitations - Azure portal doesn't support addition of auto scale
>>>>>> rules, it only allows to add a simple scale set with a given number of
>>>>>> instances. Whereas azure CLI, Powershell and REST API supports full
>>>>>> functionality.
>>>>>>
>>>>>> I have added the template to the github repo which I used to create
>>>>>> the auto scale settings which includes the ability to add a custom VM 
>>>>>> image
>>>>>> and auto scale rules. When you deploy from this template you should give
>>>>>> the URI of the VM image. you can edit auto scale rules using CLI, Power
>>>>>> shell or REST API. Azure Resource Explorer
>>>>>> <http://resources.azure.com> can be used if you choose REST API to
>>>>>> modify.
>>>>>>
>>>>>> *next tasks - 1) Have to figure out a way to pass application and
>>>>>> user data such as usernames and passwords of database, to the VM image
>>>>>> through the template. 2) Documentaion
>>>>>>
>>>>>>
>>>>>> *Load balancing*
>>>>>>
>>>>>> Following are some key terms you need to know.
>>>>>>
>>>>>> ·         Backend pool: This is a pool of virtual machines that
>>>>>> share the traffic
>>>>>>
>>>>>> ·         Probe: The load balancer can probe the health of the
>>>>>> various server instances. When a probe fails to respond, the load 
>>>>>> balancer
>>>>>> stops sending new connections to the unhealthy instances. Existing
>>>>>> connections are not impacted.
>>>>>>
>>>>>> ·         Availability set: when you have a set of virtual machines
>>>>>> for the same purpose, azure recommends to add them to an availability 
>>>>>> set.
>>>>>>
>>>>>> We can add load balancing rules such that requests coming from a
>>>>>> given URL  are shared among the VMs in backend pool. if we configure the
>>>>>> load balancer with auto scaling, VMs in the scale set can be added to the
>>>>>> backend pool so if the auto scale rules are met, it can scale in or out.
>>>>>>
>>>>>> *next tasks - 1)  research more about Probe and service health
>>>>>> checking. 2)  documentation 3) How to automate the whole deployment
>>>>>> process.
>>>>>>
>>>>> Thanks for the notes.
>>>>>
>>>>> From the next steps you have mentioned here, deployment automation
>>>>> part is very vital for the project completion. Basically we would need to
>>>>> use either the CLI or the Rest API and create a few of scripts to do a
>>>>> complete deployment on Azure. We can have a hangout today/Monday to 
>>>>> discuss
>>>>> the progress on the next tasks and the automation aspects.
>>>>>
>>>>>>
>>>>>> [1] https://github.com/osuran/Azure-templates
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 25, 2016 at 11:46 AM, Osura Rathnayake <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Isuru,
>>>>>>>
>>>>>>> Thank you. That will solve the issue.
>>>>>>>
>>>>>>> On Mon, Jul 25, 2016 at 11:44 AM, Isuru Haththotuwa <[email protected]
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi Osura,
>>>>>>>>
>>>>>>>> If you need any customizations/configurations done at the VM
>>>>>>>> startup, you can use /etc/rc.local script to do it. Also, if you 
>>>>>>>> define the
>>>>>>>> JAVA_HOME in a system wide bashrc file at /etc/bash.bashrc it won't get
>>>>>>>> deleted when the user home is removed.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 25, 2016 at 11:31 AM, Osura Rathnayake <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Imesh,
>>>>>>>>>
>>>>>>>>> You can only capture a generalized VM image, so when it's being
>>>>>>>>> generalized, all of the data in '/home' is erased. Since .bashrc is 
>>>>>>>>> also in
>>>>>>>>> '/home/<user home directory>', it's also erased. Only the data that 
>>>>>>>>> are not
>>>>>>>>> in '/home' is preserved.
>>>>>>>>>
>>>>>>>>> Okay I will try out these steps.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> On Mon, Jul 25, 2016 at 10:14 AM, Imesh Gunaratne <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Osura,
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 24, 2016 at 6:30 PM, Osura Rathnayake <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>
>>>>>>>>>>> I could successfully configure auto scaling with a VM which has
>>>>>>>>>>> a WSO2 application server installed in it. When capturing a VM, it 
>>>>>>>>>>> first
>>>>>>>>>>> get deallocated and then generalized.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ​I'm sorry I did not get this. Can you please elaborate this
>>>>>>>>>> further?
>>>>>>>>>> ​
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> So the Java home set in .bashrc is gone in the captured image of
>>>>>>>>>>> the VM. So I had to reset the Java home and also I had to manually 
>>>>>>>>>>> start
>>>>>>>>>>> the server after the startup of the VM.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ​​I think you are trying to create a VM image from a running VM
>>>>>>>>>> instance and try to reuse that. Can you please try following:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    1. Create a VM instance from Ubuntu 14.04 VM image
>>>>>>>>>>    2. Extract JDK 1.7 (JAVA_HOME) and the WSO2 server
>>>>>>>>>>    distribution (CARBON_HOME) to /opt/ directory.
>>>>>>>>>>    3. Write a brash script (init.sh) to start the WSO2 server by
>>>>>>>>>>    invoking CARBON_HOME/bin/wso2server.sh
>>>>>>>>>>    4. Update /etc/rc.local to invoke the above bash script;
>>>>>>>>>>    init.sh
>>>>>>>>>>    5. Create a VM image of this VM instance.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Is there any method developed in WSO2 to overcome this situation?
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 21, 2016 at 5:10 PM, Osura Rathnayake <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Isuru,
>>>>>>>>>>>>
>>>>>>>>>>>> That time is fine by me.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 21, 2016 at 3:44 PM, Isuru Haththotuwa <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Osura,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 21, 2016 at 11:15 AM, Osura Rathnayake <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will try using Puppet.
>>>>>>>>>>>>>> It wasn't a problem with log path/pattern, in fact I used the
>>>>>>>>>>>>>> same log path that I used last time. I believe it was a bug from 
>>>>>>>>>>>>>> Azure
>>>>>>>>>>>>>> side, please check the attached screenshots.
>>>>>>>>>>>>>> Shall we please have the meeting on Friday?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> +1. How about 2.00 - 3.0.0 PM on Friday?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thank you,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 20, 2016 at 6:50 PM, Isuru Haththotuwa <
>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Osura,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Shall we have a hangout on Thursday/ Friday to discuss and
>>>>>>>>>>>>>>> demonstrate the current progress of the project? Please let us 
>>>>>>>>>>>>>>> know your
>>>>>>>>>>>>>>> preference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 20, 2016 at 3:35 PM, Imesh Gunaratne <
>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Osura,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 4:20 PM, Osura Rathnayake <
>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is the progress so far.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Auto scaling*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Azure supports two paradigms of auto scaling, vertical and
>>>>>>>>>>>>>>>>> horizontal. Vertical scaling, also known as scale up and 
>>>>>>>>>>>>>>>>> scale down, means
>>>>>>>>>>>>>>>>> increasing or decreasing virtual machine (VM) sizes in 
>>>>>>>>>>>>>>>>> response to a
>>>>>>>>>>>>>>>>> workload. As I explained in one of my previous emails, 
>>>>>>>>>>>>>>>>> vertical auto
>>>>>>>>>>>>>>>>> scaling is achieved through monitoring rules. We can set it 
>>>>>>>>>>>>>>>>> to trigger an
>>>>>>>>>>>>>>>>> alarm when certain conditions are met and also as the action 
>>>>>>>>>>>>>>>>> we can set up
>>>>>>>>>>>>>>>>> a runbook to scale up or down. I could successfully get VMs 
>>>>>>>>>>>>>>>>> to scale up and
>>>>>>>>>>>>>>>>> down using this feature.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ​We would use horizontal scaling in most scenarios.​
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Horizontal scaling, also referred to as scale out and
>>>>>>>>>>>>>>>>> scale in, where the number of VMs is altered depending on the 
>>>>>>>>>>>>>>>>> workload.
>>>>>>>>>>>>>>>>> Horizontal scaling is achieved through virtual machine scale 
>>>>>>>>>>>>>>>>> sets (VMSS).
>>>>>>>>>>>>>>>>> One important thing about VMSS is that the VMs included 
>>>>>>>>>>>>>>>>> should be of the
>>>>>>>>>>>>>>>>> same size and have the same OS image. All the VMs in the 
>>>>>>>>>>>>>>>>> scale set are
>>>>>>>>>>>>>>>>> added to the load balancer, as a backend pool. Backend pool 
>>>>>>>>>>>>>>>>> is a pool of
>>>>>>>>>>>>>>>>> VMs which share the traffic coming via the load balancer. We 
>>>>>>>>>>>>>>>>> can add auto
>>>>>>>>>>>>>>>>> scale rules, as to when additional VMs should be added and 
>>>>>>>>>>>>>>>>> removed, based
>>>>>>>>>>>>>>>>> on the conditions. I could test some auto scale rules and 
>>>>>>>>>>>>>>>>> observed VMs
>>>>>>>>>>>>>>>>> getting added to the backend pool. But one problem is that 
>>>>>>>>>>>>>>>>> when these VMs
>>>>>>>>>>>>>>>>> getting added, it’s a whole new VM.  I’m trying to add custom 
>>>>>>>>>>>>>>>>> made VMs
>>>>>>>>>>>>>>>>> which has a wso2 product installed and configured.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ​Yes we would need a VM image with required WSO2 product
>>>>>>>>>>>>>>>> and pre-requisites to test this. At WSO2 we use Puppet​
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ​for automating the installation process [1]. With Puppet
>>>>>>>>>>>>>>>> we can use one base VM image and start a VM for any WSO2 
>>>>>>>>>>>>>>>> product. Puppet
>>>>>>>>>>>>>>>> does the WSO2 product installation at the VM startup.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note: only a limited horizontal scaling features are
>>>>>>>>>>>>>>>>> supported in the azure portal yet so I’m using REST API to 
>>>>>>>>>>>>>>>>> create and
>>>>>>>>>>>>>>>>> manage auto scaling features.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Centralized logging*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was able to get log to Log Analytics using custom logs.
>>>>>>>>>>>>>>>>> I have collected logs generated from 2 wso2 application 
>>>>>>>>>>>>>>>>> servers. You only
>>>>>>>>>>>>>>>>> have to add respective VMs to the Log analytics and set the 
>>>>>>>>>>>>>>>>> path where logs
>>>>>>>>>>>>>>>>> are located. This feature was under public preview, which 
>>>>>>>>>>>>>>>>> might have been
>>>>>>>>>>>>>>>>> one reason why it didn’t work last time when I tried.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ​Was the issue with the log file path/pattern?​ Did it work
>>>>>>>>>>>>>>>> once you remove that?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>> https://github.com/wso2/puppet-modules/wiki/Use-WSO2-Puppet-Modules-in-puppet-master-agent-Environment
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ​Thanks​
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 8:21 AM, Osura Rathnayake <
>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Isuru,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please accept my apologies I have messed up names in my
>>>>>>>>>>>>>>>>>> last email. I'm not going to be available today due to an 
>>>>>>>>>>>>>>>>>> unavoidable
>>>>>>>>>>>>>>>>>> circumstance so can we please have the meeting on Wednesday? 
>>>>>>>>>>>>>>>>>> Extremely
>>>>>>>>>>>>>>>>>> sorry if it made any inconvenience. I will update you with a 
>>>>>>>>>>>>>>>>>> detailed email
>>>>>>>>>>>>>>>>>> today for sure.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Jul 15, 2016 at 4:04 PM, Isuru Haththotuwa <
>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Osura,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Can you send a detailed updated on the current status?
>>>>>>>>>>>>>>>>>>> Shall we have a meeting on Monday to review the progress.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Jul 12, 2016 at 2:03 PM, Osura Rathnayake <
>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Imesh,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> About dynamically adding members to the load balancer,
>>>>>>>>>>>>>>>>>>>> I will cross check it with auto-scaling. I couldn't look 
>>>>>>>>>>>>>>>>>>>> into that from
>>>>>>>>>>>>>>>>>>>> auto-scaling end since I couldn't test it yet.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> about monitoring, yes we can do a POC on that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Jul 12, 2016 at 12:53 PM, Imesh Gunaratne <
>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Tue, Jul 12, 2016 at 12:09 PM, Osura Rathnayake <
>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Imesh,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> About centralized logging, I'm trying to get logs to
>>>>>>>>>>>>>>>>>>>>>> the Log Analytics using few methods supported in azure. 
>>>>>>>>>>>>>>>>>>>>>> We can either parse
>>>>>>>>>>>>>>>>>>>>>> logs in to syslogs and send to the Log Analytics or 
>>>>>>>>>>>>>>>>>>>>>> create custom logs
>>>>>>>>>>>>>>>>>>>>>> specifying the logs location. As you said, logs 
>>>>>>>>>>>>>>>>>>>>>> shouldn't be in .txt
>>>>>>>>>>>>>>>>>>>>>> extension, I got it clarified from a azure blog. Will 
>>>>>>>>>>>>>>>>>>>>>> update you soon after
>>>>>>>>>>>>>>>>>>>>>> I could resolve it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ​Right, thanks for the update!​
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No you can't dynamically add VMs to the load
>>>>>>>>>>>>>>>>>>>>>> balancer. Backend pool, where all the VMs reside, should 
>>>>>>>>>>>>>>>>>>>>>> be predefined.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ​Technically that capability should be there.
>>>>>>>>>>>>>>>>>>>>> Otherwise we would not be able to autoscale a server 
>>>>>>>>>>>>>>>>>>>>> cluster dynamically.
>>>>>>>>>>>>>>>>>>>>> ​
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> you can auto-scale using scale sets(I'm still
>>>>>>>>>>>>>>>>>>>>>> researching about it), that's the equivalent of AWS auto 
>>>>>>>>>>>>>>>>>>>>>> scaling group .
>>>>>>>>>>>>>>>>>>>>>> also you can scale up or down a VM if it exceeds a 
>>>>>>>>>>>>>>>>>>>>>> certain parameter like
>>>>>>>>>>>>>>>>>>>>>> CPU usage, using monitoring rules.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *Monitoring *
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Azure has a native monitoring tool which involves
>>>>>>>>>>>>>>>>>>>>>> collecting and tracking metrics, analyzing log files, 
>>>>>>>>>>>>>>>>>>>>>> defining custom
>>>>>>>>>>>>>>>>>>>>>> metrics and logging generated by specific applications 
>>>>>>>>>>>>>>>>>>>>>> or workloads running
>>>>>>>>>>>>>>>>>>>>>> in Virtual Machines. Azure represents monitored data in 
>>>>>>>>>>>>>>>>>>>>>> a graphical manner
>>>>>>>>>>>>>>>>>>>>>> using charts. Monitoring also facilitates triggering 
>>>>>>>>>>>>>>>>>>>>>> alarms when certain
>>>>>>>>>>>>>>>>>>>>>> conditions are met and also it can be configured to take 
>>>>>>>>>>>>>>>>>>>>>> actions on the met
>>>>>>>>>>>>>>>>>>>>>> conditions. Monitoring is done by the Diagnostic 
>>>>>>>>>>>>>>>>>>>>>> Extension and it has
>>>>>>>>>>>>>>>>>>>>>> following capabilities.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Collects and uploads the system
>>>>>>>>>>>>>>>>>>>>>> performance information from the Linux VM to the user's 
>>>>>>>>>>>>>>>>>>>>>> storage table,
>>>>>>>>>>>>>>>>>>>>>> including diagnostic and syslog information.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Enables users to customize the data
>>>>>>>>>>>>>>>>>>>>>> metrics that will be collected and uploaded.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Enables users to upload specified log
>>>>>>>>>>>>>>>>>>>>>> files to a designated storage table.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note: Azure storage tables are a non-relational,
>>>>>>>>>>>>>>>>>>>>>> key-value-pair, storage system suitable for storing 
>>>>>>>>>>>>>>>>>>>>>> massive amounts of
>>>>>>>>>>>>>>>>>>>>>> unstructured data.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We can add monitor rules so that when an alert
>>>>>>>>>>>>>>>>>>>>>> triggers it notifies the admins via email. Furthermore 
>>>>>>>>>>>>>>>>>>>>>> we can set to take
>>>>>>>>>>>>>>>>>>>>>> automated actions. Azure automate actions by running 
>>>>>>>>>>>>>>>>>>>>>> runbooks. A runbook is
>>>>>>>>>>>>>>>>>>>>>> a set of tasks that perform some automated process in 
>>>>>>>>>>>>>>>>>>>>>> Azure Automation. We
>>>>>>>>>>>>>>>>>>>>>> can create our own runbooks as well. Available runbooks 
>>>>>>>>>>>>>>>>>>>>>> include,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Restart VM
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Stop VM
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Remove VM
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Scale up VM
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ·         Scale down VM
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When scaling up it sets the virtual machine to the
>>>>>>>>>>>>>>>>>>>>>> next larger size within the size group and when scaling 
>>>>>>>>>>>>>>>>>>>>>> down it sets the
>>>>>>>>>>>>>>>>>>>>>> virtual machine to the next smaller size within the size 
>>>>>>>>>>>>>>>>>>>>>> group.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> More about runbooks and automation [1]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ​Sounds good, will us be able to do a POC on this?​
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *Auto scaling *
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Auto-scaling is the process of dynamically allocating
>>>>>>>>>>>>>>>>>>>>>> the resources required by an application to match 
>>>>>>>>>>>>>>>>>>>>>> performance requirements.
>>>>>>>>>>>>>>>>>>>>>> Virtual machine scale sets are an Azure Compute resource 
>>>>>>>>>>>>>>>>>>>>>> you can use to
>>>>>>>>>>>>>>>>>>>>>> deploy and manage a set of identical VMs. With all VMs 
>>>>>>>>>>>>>>>>>>>>>> configured the same,
>>>>>>>>>>>>>>>>>>>>>> VM scale sets are designed to support true auto-scale  
>>>>>>>>>>>>>>>>>>>>>> no pre-provisioning
>>>>>>>>>>>>>>>>>>>>>> of VMs is required – and as such makes it easier to 
>>>>>>>>>>>>>>>>>>>>>> build large-scale
>>>>>>>>>>>>>>>>>>>>>> services targeting big compute, big data, and 
>>>>>>>>>>>>>>>>>>>>>> containerized workloads [2].
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note: I couldn’t practically do this as my azure free
>>>>>>>>>>>>>>>>>>>>>> account lets me have only 4 cores and I have used all of 
>>>>>>>>>>>>>>>>>>>>>> them on my current
>>>>>>>>>>>>>>>>>>>>>> deployment. I’m getting a new azure account from one of 
>>>>>>>>>>>>>>>>>>>>>> my friends in a day
>>>>>>>>>>>>>>>>>>>>>> so hopefully I will do this on it and update you.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ​Great! Thanks!​
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/documentation/articles/automation-intro/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/documentation/articles/virtual-machine-scale-sets-overview/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 11, 2016 at 9:54 AM, Imesh Gunaratne <
>>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 7:11 PM, Osura Rathnayake <
>>>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Mentors,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In addition to refining the membership scheme code,
>>>>>>>>>>>>>>>>>>>>>>>> I looked into following features of Azure.
>>>>>>>>>>>>>>>>>>>>>>>> ​
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ​Good findings Osura, please find few questions
>>>>>>>>>>>>>>>>>>>>>>> inline:​
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ​
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> *Azure dynamic load balancing*
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Azure has a native load balancer which is very easy
>>>>>>>>>>>>>>>>>>>>>>>> to configure. It’s a layer 4 (TCP, UDP) load balancer 
>>>>>>>>>>>>>>>>>>>>>>>> which helps to spread
>>>>>>>>>>>>>>>>>>>>>>>> traffic among healthy virtual machines. Following are 
>>>>>>>>>>>>>>>>>>>>>>>> some key terms you
>>>>>>>>>>>>>>>>>>>>>>>> need to know.
>>>>>>>>>>>>>>>>>>>>>>>> ​
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ​Can members be dynamically added and removed
>>>>>>>>>>>>>>>>>>>>>>> to/from a load balancer? To check this we may need to 
>>>>>>>>>>>>>>>>>>>>>>> explore how
>>>>>>>>>>>>>>>>>>>>>>> autoscaling works. On AWS this is handled with 
>>>>>>>>>>>>>>>>>>>>>>> autoscaling groups [3]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> *Capturing Virtual Machine Images as templates*
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Azure provides the feature of generalizing and
>>>>>>>>>>>>>>>>>>>>>>>> capturing virtual machines so that they can be used as 
>>>>>>>>>>>>>>>>>>>>>>>> templates. This is
>>>>>>>>>>>>>>>>>>>>>>>> very useful and time saving when the production 
>>>>>>>>>>>>>>>>>>>>>>>> environment has many
>>>>>>>>>>>>>>>>>>>>>>>> instances of the same kind of virtual machine. When 
>>>>>>>>>>>>>>>>>>>>>>>> the virtual machine is
>>>>>>>>>>>>>>>>>>>>>>>> being generalized all the data in user directories are 
>>>>>>>>>>>>>>>>>>>>>>>> erased so better to
>>>>>>>>>>>>>>>>>>>>>>>> have wso2 product directory not in "/home/*". More 
>>>>>>>>>>>>>>>>>>>>>>>> about this can be found
>>>>>>>>>>>>>>>>>>>>>>>> here [2].
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Once the virtual machine is captured, it is stored
>>>>>>>>>>>>>>>>>>>>>>>> in the storage account that is associated with the 
>>>>>>>>>>>>>>>>>>>>>>>> virtual machine. You can
>>>>>>>>>>>>>>>>>>>>>>>> either download this or use directly by referring to 
>>>>>>>>>>>>>>>>>>>>>>>> the URI when you want
>>>>>>>>>>>>>>>>>>>>>>>> to make other virtual machines with this template. 
>>>>>>>>>>>>>>>>>>>>>>>> What would be awesome is
>>>>>>>>>>>>>>>>>>>>>>>> if we can fully configure the virtual machine with a 
>>>>>>>>>>>>>>>>>>>>>>>> given product and make
>>>>>>>>>>>>>>>>>>>>>>>> it available to users.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ​Yes, this is mandatory. Otherwise we would not be
>>>>>>>>>>>>>>>>>>>>>>> able to autoscale a server cluster.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ​​I'm sorry I may have missed, how did it go with
>>>>>>>>>>>>>>>>>>>>>>> centralized logging?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>>>>>>>>>> http://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroup.html
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ​Thanks​
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-capture-image/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 6, 2016 at 12:18 PM, Osura Rathnayake <
>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Akila,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Please refer to the screenshots that I have
>>>>>>>>>>>>>>>>>>>>>>>>> attached. When I updated localMemberPort to 4200, I 
>>>>>>>>>>>>>>>>>>>>>>>>> can see it being
>>>>>>>>>>>>>>>>>>>>>>>>> reflected in logs when members are joining. So should 
>>>>>>>>>>>>>>>>>>>>>>>>> I still make
>>>>>>>>>>>>>>>>>>>>>>>>> modifications in the code?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .gitignore was added.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> okay I will write test cases in testNG and update
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 6, 2016 at 9:06 AM, Akila Ravihansa
>>>>>>>>>>>>>>>>>>>>>>>>> Perera <[email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Jul 5, 2016 at 11:38 AM, Osura Rathnayake
>>>>>>>>>>>>>>>>>>>>>>>>>> <[email protected]> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Thanks and Regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Isuru H.
>>>>>>>>>>>>>>>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Thanks and Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Isuru H.
>>>>>>>>>>>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Thanks and Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Isuru H.
>>>>>>>>>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Regards,
>>>>>>>>>>> Osura Rathnayake
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Osura Rathnayake
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks and Regards,
>>>>>>>>
>>>>>>>> Isuru H.
>>>>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Osura Rathnayake
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Osura Rathnayake
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks and Regards,
>>>>>
>>>>> Isuru H.
>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Osura Rathnayake
>>>>
>>>
>>>
>>>
>>> --
>>> *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
>>>
>>>
>>
>>
>> --
>> Regards,
>> Osura Rathnayake
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>


-- 
Regards,
Osura Rathnayake
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to