Story #8651

[Workbench] Add "work unit" Ruby interface definition

Added by Brett Smith over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assigned To:
-
Category:
Workbench
Target version:
-
Start date:
03/07/2016
Due date:
% Done:

0%

Estimated time:
Story points:
-

Description

This provides a generic programmatic interface for work units to expose:

  • State
  • Progress
  • Child work units, including UUIDs and names
  • Output
  • Logs (if available)
  • Runtime

Related issues

Related to Arvados - Story #8647: [Workbench] "Work unit" user interfaceResolved03/07/2016

Blocks Arvados - Story #8650: [Workbench] Container implements Work Unit interfaceResolved

Blocks Arvados - Story #8649: [Workbench] Pipeline instance implements Work Unit interfaceClosed03/07/2016

Blocks Arvados - Story #8648: [Workbench] Job task implements Work Unit interfaceClosed03/07/2016

Blocks Arvados - Story #8652: [Workbench] Job implements Work Unit interfaceClosed03/07/2016

History

#1 Updated by Brett Smith over 4 years ago

Radhika to write a list of method signatures that we need. In order to implement the views that we currently have, write a list of method signatures for our work units (including names of methods, and the list of their arguments), and the return value of each of those methods.

#2 Updated by Radhika Chippada over 4 years ago

Some notes about the ruby language specific aspects of this implementation.

  • There is no support for inheriting behavior from multiple sources (interfaces)
    • So, we can’t do: Job < ArvadosBase, WorkUnit
  • Instead we can do something like this:
    class WorkUnit < ArvadosBase
       def child_work_units
         raise "Not implemented" 
       end
    end
    
    class Job < WorkUnit (instead of current Job < ArvadosBase)
    
    
  • Only when the “child_work_units” method is invoked, the exception is raised. That is, just by declaring that Job implements WorkUnit, we will not get the exception (as in a java interface). Instead, only when we stumble upon it, we get the exception.
  • Tom: Is this the strategy we are planning to use?

#3 Updated by Tom Clegg over 4 years ago

We should document the work unit interface -- perhaps in app/models/work_unit.rb, in a class called WorkUnit. (In Ruby, an interface essentially is just documentation.)

Each object we intend to display using a generic work unit view/partial must have a "work_unit" method that returns an object that satisfies the work unit interface.

class Job
  def work_unit label
    JobWorkUnit.new(self, label)
  end
end

class WorkUnit
  # This is just an abstract class that documents the WorkUnit interface; a
  # class can implement the interface without being a subclass of WorkUnit.
  def label
    # returns the label that was assigned when creating the work unit
  end
  def uuid
    # returns the arvados UUID of the underlying object
  end
  def children
    # returns an array of child work units
  end
end

class ProxyWorkUnit < WorkUnit
  def initialize proxied, label
    self.label = label
    self.proxied = proxied
  end
  def label
    self.label
  end
  def uuid
    self.proxied.uuid
  end
end

class JobWorkUnit < ProxyWorkUnit
  def children
    n = -1
    self.proxied.job_tasks.map do |t|
      n++
      t.work_unit("task #{n}")
    end
  end
end

#4 Updated by Brett Smith about 4 years ago

  • Status changed from New to Closed

We've decided #8876 is the most useful implementable unit here.

Also available in: Atom PDF