You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by ch...@apache.org on 2013/02/19 22:04:50 UTC

svn commit: r1447924 - in /uima/sandbox/uima-ducc/trunk/src/main/doc: ./ ducc-completion.txt

Author: challngr
Date: Tue Feb 19 21:04:50 2013
New Revision: 1447924

URL: http://svn.apache.org/r1447924
Log:
UIMA-2682
List of tasks to complete to bring DUCC to Release 1 state.

Added:
    uima/sandbox/uima-ducc/trunk/src/main/doc/
    uima/sandbox/uima-ducc/trunk/src/main/doc/ducc-completion.txt

Added: uima/sandbox/uima-ducc/trunk/src/main/doc/ducc-completion.txt
URL: http://svn.apache.org/viewvc/uima/sandbox/uima-ducc/trunk/src/main/doc/ducc-completion.txt?rev=1447924&view=auto
==============================================================================
--- uima/sandbox/uima-ducc/trunk/src/main/doc/ducc-completion.txt (added)
+++ uima/sandbox/uima-ducc/trunk/src/main/doc/ducc-completion.txt Tue Feb 19 21:04:50 2013
@@ -0,0 +1,152 @@
+February 19, 2003
+
+Define DUCC Release 1
+   Completion Goal: 2Q13 
+
+   Terminology
+   
+       DUCC Job
+
+	   As defined for DUCC, a Job is the processing of a collection of work items. The collection is
+	   defined by a Collection Reader (CR) and work items are processed by an Analysis Engine (AE)
+	   that is scaled out by DUCC. CASes produced by the CR typically contain references to the work
+	   items and the input data is read directly by the AE instances. DUCC allocates resources for
+	   the CR and some number of AE's, managing their lifetime and maintaining meta data on the job:
+	   logs, performance information, etc.
+
+       DUCC Service
+    
+       In DUCC a Service is a process that performs some function on behalf of a DUCC Job, another
+       DUCC Service, or a user application.  The most common and fully supported type of service is
+       a UIMA-AS service fully managed by DUCC.  DUCC also supports services that are not UIMA-AS
+       services. DUCC manages service scale out.
+
+       DUCC Arbitrary Process
+
+       In DUCC an Arbitrary Process (AP) is any user-submitted process managed by DUCC that is not
+       a DUCC Job or DUCC Service. Arbitrary processes are singletons, with no scale out support.
+
+       DUCC Agent
+
+       The DUCC agent is a process running on every node in the DUCC cluster.  The Agent manages all
+       work on behalf of users on each node.  It also gathers local performance data (both system
+       and application-level) and enforces resource boundaries on the user's processes (see CGroups,
+       below).
+
+   Completion tasks for Release 1
+
+   1.  Debugging interface for DUCC Jobs
+       
+       This is an extension to DUCC's submit CLI to launch a Job as a single threaded process
+       suitable for development and debug. The process can be deployed locally on the client machine
+       or remotely on a DUCC machine. Debugging is initiated by adding a flag to the normal ducc
+       submit.
+
+       Requirements:
+
+          1. Run and debug a DUCC Job in a local eclipse session, using the same interface that is
+          used to submit jobs to DUCC.
+
+          2. Alternate flag switch to ducc_submit to run as an Arbitrary Process, so that DUCC 
+	  will run the process in a remote DUCC machine.  This uses console redirection and
+	  Eclipse remote debugging.
+  
+
+   2.  Finish support for Arbitrary Processes.
+
+       In DUCC usage, an Arbitrary Process (AP) is a process executed on behalf of a developer that
+       is not a UIMA or UIMA-AS pipeline managed as a DUCC job.  DUCC beta-0.7.3 contains initial
+       support for APs with the following tasks not fully completed and/or tested and verified:
+
+          a) Java CLI and API to support AP
+          b) "cancel on interrupt" support (submitter is monitoring the AP via 
+             redirected console and terminates the console via ctl-C. The AP
+             job be terminated.)
+          c) Redirection of stdin to the remote AP.  Currently only stdout and stderr
+             are redirected from the remote AP.
+          d) Support for X11. On submission, capture the local DISPLAY information, 
+             initiate authorization for the remote host to connect, and when the
+             remote host starts, direct the DISPLAY to the initiating X11 session.
+          e) Insure this support can open an xterm from a DUCC allocated machine to the
+             user's X11 session.
+          f) Web server support for APs
+
+   3. CGroups
+
+      From Wikipedia (http://en.wikipedia.org/wiki/Cgroups): cgroups (control groups) is a Linux
+      kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of
+      process groups.
+
+      DUCC support for CGroups will be used to enforce resource boundaries for multiple users
+      on large-memory multi-core machines.
+
+      a) Basic implementation in the DUCC Agents.
+      b) Presentation in the DUCC Web server.
+
+   
+   4.  Sample applications using Apache UIMA text analytics.
+
+       Supply additional code and documentation as needed to demonstrate use of DUCC to
+       deploy and run the sample applications from the existing UIMA and UIMA-AS projects.
+      
+       This encompasses:
+       a) A source ingestion-like / text-processing application
+       b) A CAS-in CAS-out application
+       c) Document this in the Duccbook
+
+   5.  System-verification test suite:
+          
+       Clean and donate the current system-verification test suite.
+
+       A comprehensive test driver for system-level verification of DUCC has been developed along
+       with DUCC itself.  This driver is based on a certain amount of data scraped from application
+       logs gathered during various UIMA development efforts at IBM.  It is necessary to scrub this
+       data to remove userids and insure that no proprietary information is accidentally released.
+
+       Included in this test suite:
+          a) a simple scaled-out UIMA-AS job used for initial installation verification
+          b) a set of UIMA-AS services for use by the test suite
+          c) a database of simulated jobs 
+          d) a test driver capable of dispatching and managing the test jobs to simulate a large,
+             multi-user development environment running over arbitrarily small to arbitrarily
+             large heterogeneous clusters.
+          e) documentation
+
+    6.  Web Server support for DUCC Services
+        Current DUCC web server support for services is minimal.  Most service interaction
+        including query is entirely command-line driven.
+
+        Support includes:
+           Ability to start, stop, and modify services
+
+        Presentation
+           Display service registrations
+           Display relationship of service instances to registrations
+           Display relationship of jobs to service instances
+           Logging and performance information
+
+
+   7. Services Manager CLI/API needs authentication
+      a) Insure registering user is who he says she is
+      b) Insure only the "owning" user can take actions on their services - modify,
+         unregister, etc.
+
+      Most of this code can be copied from the DuccSubmit CLI/API
+
+   8. Resource Manager Hot Start
+
+      Resource Manager should be able to reconstruct state from the Orchestrator publication in
+      conjunction with Agent publications, so it can be stopped and started "hot" (without affecting
+      state of running work).
+
+   9. Services Manager Restart Policy
+
+      Implement policy for restarting failed services, and halting restart if the service continues
+      to fail.
+
+  10. Build formal API
+
+      Implement a proper API for submit, and cancel, reserve, and unreserve. Coordinate with the
+      service manager API so they're consistent.
+
+  11. Complete, correct, and clean-up formal documentation (the "duccbook").