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