Hi Imesh, Sure we shall have a meeting on Monday to review the progress. I will send a detailed update on the current status by tonight. Sorry for the delay.
Thanks, On Fri, Jul 15, 2016 at 4:04 PM, Isuru Haththotuwa <isu...@wso2.com> 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 <osura...@gmail.com> > 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 <im...@wso2.com> wrote: >> >>> On Tue, Jul 12, 2016 at 12:09 PM, Osura Rathnayake <osura...@gmail.com> >>> 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 <im...@wso2.com> >>>> wrote: >>>> >>>>> On Thu, Jul 7, 2016 at 7:11 PM, Osura Rathnayake <osura...@gmail.com> >>>>> 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 <osura...@gmail.com >>>>>> > 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 < >>>>>>> raviha...@wso2.com> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
