Test Plan Scenario 26

This scenario tests the implementations of EMI-ES in the various middleware stacks. To this end clients of each of the middlewares are used to interact with service endpoints of each of the other middlewares. It is understood that a client of any middleware is capable of communicating with the same middleware's service implementations.

Test campaign March 2013

During the March of 2013, a final test campaign was conducted with a specific focus on the Java client library (HiLA). Generally, the test results were successful, but also revealed some flaws that were fixed on the way. Whereas activity creation, management, and information had been tested previously, we particularly focused the delegation service.

Tests

ID Service involved Description Result
01 Delegation, ActivityCreation Create a delegation, add it's id to the ADL, submit the job. The delegation must be used during job execution, e.g. to transfer files. The ADL shown below guarantees this and involves two GridFTP servers. SUCCESS
02 ActivityCreation, ActivityInfo Verify that an activity with clientDataPush=true remains pending until notified to start. Import an additional file into the activity's StageInDirectory. SUCCESS
03 ActivityManagement After submission of an ADL that sets clientDataPush=true, start the job and run it successfully. SUCCESS

We used the following simple ADL to trigger the job and transfers.

<adl:ActivityDescription xmlns:adl="http://www.eu-emi.eu/es/2010/12/adl">
  <adl:ActivityIdentification>
    <adl:Name>A Simple copy job.</adl:Name>
  </adl:ActivityIdentification>
  <adl:Application>
    <adl:Executable>
      <adl:Path>/bin/cat</adl:Path>
      <adl:Argument>input</adl:Argument>
    </adl:Executable>
    <adl:Input>input</adl:Input>
    <adl:Output>stdout</adl:Output>
    <adl:Error>stderr</adl:Error>
  </adl:Application>
  <adl:DataStaging>
    <adl:ClientDataPush>true</adl:ClientDataPush>
    <adl:InputFile>
      <adl:Name>input</adl:Name>
      <adl:Source>
        <adl:URI>gsiftp://cream-47.pd.infn.it/var/cream_es_sandbox/testers/CN_Bjoern_Hagemeier_OU_Forschungszentrum_Juelich_GmbH_O_GridGermany_C_DE_testers_eu_emi_eu_Role_NULL_Capability_NULL_tst07/95/CR_ES957809207/OSB/stdout</adl:URI>
      </adl:Source>
    </adl:InputFile>
    <adl:OutputFile>
      <adl:Name>stdout</adl:Name>
      <adl:Target>
        <adl:URI>gsiftp://zam052v07.zam.kfa-juelich.de/home15/bjoernh/tsi_submit_3878.copy</adl:URI>
      </adl:Target>
    </adl:OutputFile>
    <adl:OutputFile>
      <adl:Name>stdout</adl:Name>
    </adl:OutputFile>
    <adl:OutputFile>
      <adl:Name>stderr</adl:Name>
    </adl:OutputFile>
  </adl:DataStaging>
</adl:ActivityDescription> 

Problems revealed

ID Description Fixed (Y/N)
1 UNICORE client and server handled proxy certificates incorrectly, or rather incompletely. When using e.g. a VOMS proxy certificate in the client and creating a delegation from it, they did not put the full certificate chain into the Delegation service (PutDelegation). This lead to Problems in the ARC (see #2) and CREAM (see #3) implementations. Yes, UNICORE clients and servers put the complete delegation chain now, such that it can be verified and used. r16053, r16045, ...
2 Arc server implementation crashes, when incomplete delegation proxy chain is sent in the PutDelegation operation ?
3 CREAM implementation accepts incomplete proxy chain, but globus_copy_cmd fails with a segmentation fault. ? (solution could be WONTFIX, as this is a globus issue)
4 A malformed gsiftp URL containing a colon after the hostname, but no port number (gsiftp://host:/path), leads to the port being interpreted as 0 in Arc. A more detailed warning message will be implemented. ?
5 A malformed gsiftp URL containing a colon after the hostname, but no port number (gsiftp://host:/path), leads to error messages that are difficult to interpret (parsing error) in UNICORE. This is rather a bug in the globus-url-copy command, which should show a more detailed warning. WONTFIX
6 Some jobs were flagged as successful in the client library due to a wrong mapping of EMI-ES states Yes (r16055)
7 The HiLA abstract job model had no support for clientDataPush Yes (r16049)
8 HiLA did not use the delegation client Yes (r16047)
9 UNICORE EMI-ES server implementation did not publish Delegation endpoint correctly Yes (r16046)

Detailed list

ActivityCreation port type

OperationSorted ascending Test Description
CreateActivity This has been called successfully in all implementations. We have run jobs with andn without clientDataPush.

ActivityManagement port type

Operation Test Description
PauseActivity Not yet implemented for HiLA EMI-ES.
ResumeActivity Not yet implemented for HiLA EMI-ES.
NotifyService This has been used successfully when running jobs with clientDataPush and actually pushing data from the client into the Activities input directory.
CancelActivity CREAM tested. ARC tested, shows slow handling, but can be due to asynchronous updates. Tested in UNICORE.
WipeActivity Tested in all implementations to cleanup after the creation of jobs. Slow in Arc for a cancelled activity.
RestartActivity Not tested, no mapping in HiLA.
GetActivityStatus Tested against all implementations. It is called via the HiLA Job.status() method.
GetActivityInfo Tested against all implementations, this is where we retrieved the information about input/output/session directories.

ActivityInfo port type

HiLA internally manages a reference to the ActivityInfo port type, but does not make use of it. All relevant information is retrieved from the ActivityManagement port type.

Delegation port type

HiLA uses only two of the methods to handle delegations. The termination time of the proxy is handled internally, but could be retrieved from the server as well. There's room for improvement.

Operation Test Description
getVersion  
getInterfaceVersion  
getServiceMetadata  
getProxyReq  
getNewProxyRequest  
renewProxyReq Called in all implementations to initiate the creation of a proxy.
putProxy Called successfully against all implementations. Proxy was usable, as demonstrated by data staging.
getTerminationTime  
destroy  

ResourceInfo port type

This port type does not have a natural mapping in the HiLA API and was therefore not tested.

Tests

Test Description Expected Result Result
Arc -> CREAM Arc -> UNICORE CREAM -> Arc CREAM -> UNICORE UNICORE -> Arc UNICORE -> CREAM
IT-26-NO-AUTHZ Access services, but authorization is not granted. Should return an AccessControlFault           Yes

Issues

Description Tracker URL Status (Pending/Solved)
Specify whether PEM header and footer are to be transferred for proxy certificates. The UNICORE implementation sends proxy without, whereas CREAM-Client expects the header and footer.   Solved, will send ----BEGIN... etc. header and footer

Deployed Middleware

The following endpoints have been used, before EMIR support was fully integrated. A testing campaign in March 2013 used the EMIR endpoint at http://emitbdsr1.cern.ch:9126/.

ARC

2 services are running at

Services implement all PortTypes of EMI ES and authorize members of testers.eu-emi.eu dteam VOs.

CREAM

UNICORE

In order to get access, please send Björn Hagemeier <b.hagemeier@fz-juelich.de> an email with your DN that you use to access the testbed resources.

-- BjoernHagemeier - 12-Mar-2012

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r13 - 2013-03-12 - BjornHagemeierExCern
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback