We need to consider deployment pattern 1 in clustering guide [1]. To address this pattern though test framework, type of the elb instance should be "lb_worker" and mgt instance details should be kept separately. In order to generate service URLs, we can check lb instance type, if it is "lb_worker" and no "lb_manager" instance configs present, then build the management node environment with instance defined with the type "manager".
<instance name="lbw002" type="lb_worker" servicePortType="nhttpport"> <workerHost>esb.wso2con.com <http://mgt.esb.wso2con.com> </workerHost> <httpport>9763</httpport> <httpsport>9443</httpsport> <nhttpsport>8243</nhttpsport> <nhttpport>8280</nhttpport> <webContext>/</webContext> </instance> <instance name="asm001" type="manager" servicePortType="nhttpport"> <host>mgt.wso2con.com <http://mgt.esb.wso2con.com></host> <httpport>9764</httpport> <webContext>/</webContext> <httpsport>9444</httpsport> <nhttpsport>8244</nhttpsport> <nhttpport>8282</nhttpport> </instance> [1]http://docs.wso2.org/pages/viewpage.action?pageId=32346071 Thanks, On Fri, Nov 8, 2013 at 10:04 AM, Malintha Adikari <malin...@wso2.com> wrote: > Hi, > > Automating tests in clustered environment - Storing configuration details > for different clustering patterns. > > *Context of product group instances for clustering environment test > scenario* > > Product groups instance contains the basic configuration details for each > product deployment instance in a test scenario. ( host, http port, https > port etc..). In clustered environment the product group instances should > have one or more load balancer instances. As there are different > Worker/Manager Clustering Patterns, the structure of the load balancer > instances/instances may differ from pattern to pattern. The structure of > the product instance is depending on the number of load balancing nodes > participating to the cluster. If it is one, the load balancer node should > be able manage both service and management requests. So that the test > framework's load balancer instance should contain both worker and manager > domain details in order to generate the appropriate URL's. To address this > issue the "lb_worker_manager" instance type is proposed. It contains both > worker host and the manager host. Ex: Following is the proposed instance > for a scenario ESB worker and manager nodes fronted by single ELB node. > > <instance name="lbw001" type="lb_worker_manager" > servicePortType="nhttpport"> > <workerHost>esb.wso2con.com</workerHost> > <managerHost>mgt.esb.wso2con.com</managerHost> > <httpport>9763</httpport> > <httpsport>9443</httpsport> > <nhttpsport>8243</nhttpsport> > <nhttpport>8280</nhttpport> > <webContext>/</webContext> > </instance> > > A pattern where there are more than one load balancer nodes participating > for the cluster can have only one host details depending on the nodes they > front. As an example a load balancer node that fronts manager nodes > cluster is mapped like follows > > <instance name="lbw002" type="lb_manager" > servicePortType="nhttpport"> > <managerHost>mgt.esb.wso2con.com</managerHost> > <httpport>9763</httpport> > <httpsport>9443</httpsport> > <nhttpsport>8243</nhttpsport> > <nhttpport>8280</nhttpport> > <webContext>/</webContext> > </instance> > > The service URL generation logic will be changed according to the proposed > structures. > > Regards, > Malintha Adikari > > > On Thu, Oct 31, 2013 at 8:56 AM, Dharshana Warusavitharana < > dharsha...@wso2.com> wrote: > >> Hi Malintha, >> >> I think configuration should be something like >> <instance name="asw001" type="standalone" nonBlockingEnabled="true"> >> >> Here basically we need NHTTP for ESB and LB only. As out initial design >> we check whether NHTTP and NHTTPS potts are null or not to assign this >> to url. >> Though +1 fo introducing a configuration. >> >> But still the servicePortType="nhttpport" does not reflect actually what >> we need to do here >> >> this should be either >> <instance name="asw001" type="standalone" nonBlockingEnabled="true"> >> >> or >> <instance name="asw001" type="standalone" transportType="nonBlocking >> "> >> >> Thank You, >> Dharshana. >> >> >> On Wed, Oct 30, 2013 at 11:11 PM, Malintha Adikari <malin...@wso2.com>wrote: >> >>> *Running the test in product/stratos modes* >>> >>> The tenant which is used to build the test environment decides whether >>> test is running on product or stratos modes. In the case of the super >>> tenant user is used to build the test environment , the test is running on >>> product mode. If the tenant is any other it runs in stratos mode. As an >>> example : >>> Following is ESB test base class. >>> >>> >>> public class ESBIntegrationTest { >>> >>> ................................ >>> ................................ >>> >>> protected void init() throws URISyntaxException, SAXException, >>> IOException, XMLStreamException, >>> ConfigurationMismatchException { >>> >>> .............................. >>> .............................. >>> >>> automationContextBuilder = new >>> AutomationContextBuilder("ESB","asw001"); >>> automationContextBuilder.build("wso2.com", "user1"); >>> } >>> >>> ......................... >>> } >>> >>> With the above configuration uses a tenant which domain is 'wso2.com' >>> (not the super tenant -carbon.super) and the test will be executed in >>> stratos mode. >>> >>> >>> >>> Adding custom service port type to instance nodes >>> >>> With the improvement Test Automation Framework users can use custom >>> service port type in the case of service URL generation. This feature is >>> essential for ESB tests as it uses the nhttp/nhttps ports for the service >>> URL for generating. Users have to mention the type of the port which is >>> expected to be used to generate the URL in the PlatformContext - > >>> ProductGroup - > instance node. Also that mentioned port should be included >>> as a child element of the instance node. As an example : >>> >>> >>> <platform> >>> <productGroup name="ESB" clusteringEnabled="true"> >>> <instance name="asw001" type="standalone" >>> servicePortType="nhttpport"> >>> <host>localhost</host> >>> <httpport>9763</httpport> >>> <webContext></webContext> >>> <httpsport>9443</httpsport> >>> <nhttpport>8280</nhttpport> >>> <nhttpsport>8280</nhttpsport> >>> <qpidport>123</qpidport> >>> <nhttps1>875</nhttps1> >>> <nhttps2>875</nhttps2> >>> <cutomport>8085</customport> >>> </instance> >>> >>> >>> >>> This configuration uses the port which is given as the 'serivePortType' >>> for service for URL generation ( In this case it is set to 'nhttp'). The >>> instance node should have that mentioned 'nhttpport' in list of service >>> port elements. Absense of that will give an execption at the begining of >>> the test execution. >>> >>> Also users can define custom ports in the port list and use them for >>> srvice URL generation when it needs. >>> >>> >>> On Thu, Oct 24, 2013 at 5:18 PM, Malintha Adikari <malin...@wso2.com>wrote: >>> >>>> Hi, >>>> >>>> The progress of the Test Automation Framework re-factoring is as >>>> follows. >>>> >>>> *1. Improved user population logic for product/platform execution >>>> environments* >>>> >>>> Improved the user population logic for populate for both product and >>>> platform execution modes. Users have to change the executionEnvironment >>>> tag content inside the configurations to change the environment of >>>> execution. Ex: if a user want to run the test for platform environment, the >>>> content of the automation.xml file should be change like >>>> >>>> <configurations> >>>> ...................... >>>> ..................... >>>> <!-- >>>> Change this to product/platform to execute test on specific >>>> environment >>>> --> >>>> <executionEnvironment>*platform*</executionEnvironment> >>>> >>>> ..................... >>>> ..................... >>>> </configurations> >>>> >>>> Note: Only product and platform environments are allowed as valid >>>> environments. >>>> >>>> Each execution mode supports multi-tenant and single tenant mode user >>>> population. Ex: if the user want to run tests in multi-tenant enabled mode, >>>> the configuration in *automation.xml* should be as follows >>>> >>>> >>>> <configurations> >>>> .................... >>>> ................... >>>> <!-- >>>> Change this to true/false to execute test with user mode or >>>> tenant mode >>>> --> >>>> <multiTenantMode>*true*</multiTenantMode> >>>> ................... >>>> .................. >>>> >>>> </configurations> >>>> >>>> >>>> >>>> *2. Added check point to catch semantic errors in automation.xml and >>>> generate an exception when it found such an semantic error* >>>> >>>> *Platform context* of the automation.xml file should be in consistent >>>> with the execution environment. The content of the automation.xml file is >>>> expected to be followed these rules to accepted it as correct >>>> configurations. >>>> >>>> If user is set the execution mode as >>>> >>>> 1. Product >>>> >>>> a). There should be only one product group under platform >>>> context. >>>> >>>> b). There should be at least one standalone typed >>>> instance node in the product group. >>>> >>>> >>>> 2. Platform >>>> >>>> a). Every product group should have a load balancer >>>> manager (lb_manager) typed instance node >>>> >>>> >>>> >>>> >>>> On Wed, Oct 16, 2013 at 11:32 AM, Malintha Adikari >>>> <malin...@wso2.com>wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> Completed implementing the user population logic which is one of the >>>>> initial task of the test execution cycle. User polulation is supported for >>>>> both multi- tenant mode and single-tenant mode. >>>>> >>>>> Implemented a logic to allow users to add custom propertied to the >>>>> specific contexts in the automation.xml and refactored the XML schema file >>>>> to validate the change. Now users are allowed to add custom properties for >>>>> following context modules in automation.xml file >>>>> >>>>> >>>>> - datasources->datasource >>>>> >>>>> >>>>> >>>>> - platform ->productGroup->instance >>>>> >>>>> >>>>> >>>>> - tools -> selenium -> browser >>>>> >>>>> >>>>> Note - Adding custom elements for other modules or removing existing >>>>> elements from any module will be invalidated by the XML schema file. >>>>> According to the current validation logic one has to change the XML schema >>>>> file in Automation Framework (path - >>>>> *org.wso2.carbon.automation.engine/src/main/resources/automationXMLSchema.xsd*) >>>>> to do any other changes to the automation.xml file. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Software Engineer, >>> WSO2 Inc. http://wso2.com >>> (M) +94(71) 2312958 >>> >> >> >> >> -- >> >> Dharshana Warusavitharana >> Senior Software Engineer , Test Automation >> WSO2 Inc. http://wso2.com >> email : dharsha...@wso2.com <dharsha...@wso2.com> >> Tel : +94 11 214 5345 >> Fax :+94 11 2145300 >> cell : +94772202595 >> blog : http://dharshanaw.blogspot.com >> >> lean . enterprise . middleware >> > > > > -- > Software Engineer, > WSO2 Inc. http://wso2.com > (M) +94(71) 2312958 > -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear.
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev