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/>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
