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
