Hi All, Please read my blog if you have some free time [1] and your suggestions and comments are most welcome. I have updated it with posts on Azure Membership Scheme, Centralized logging in Azure and monitoring in Azure.
[1] http://osuran.blogspot.com/ Thank you, 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. > > [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 > -- Regards, Osura Rathnayake
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
