iPlant Goals & Objectives

What is the community?

• resource providers (where resources are domain resources & tools)
  • ease of user management (SSO, ease of enrollment/registration)
  • ease of group management (inherit across providers; must align with user mgmt)
  • data access across providers (iRODS)
  • manage /quota/access at various levels (meter and throttle)
  • resource and services "federation" (sharability of workflow between services)
  • integration of 3rd party tools
    

• end-users / consumers (domain scientists)
  • SSO, linked to home institution
  • ability to form ad-hoc groups
  • ability to control access with keys/tokens that can be honored across services and providers, and yet limited based on time or something
  • can use web/API and command line apps w/ VO-based credentials (command-line apps where different libraries can be pulled in, can do more than just ssh)
  • keep data in one location, integration with many analysis platforms
  • activity dashboard, messaging and alerts, consolidated from providers
• misc notes
  • using google for calendar, document creation (wiki for final doc, but for the actual drafting, they go to google); use doodle for meeting scheduling
  • iPlant does not have grouper installed
    

• developers
  • user mgmt out of the box
  • access to federated resources
  • ability to meter and throttle (because developers easily create DOS situations; need handles in place so they know who is doing what)
  • unified sharing, reporting, dashboards
  • ease of integration to resources that need significant permissions (i.e. running compute data intensive tasks)
  • become part of a "market place" model
• misc notes
  • privacy of data is not a huge concern at this point from a contractual point of view, tho' individual researchers may be anxious about research not being exposed until the publication happens
  • internalization of VO may start to impact the importance of the privacy/restriction of data; possible assertion that if the data is under contractual restrictions, then maybe it is not a fit for iPlant
    

• educators (classroom, workshops)
  • make all iPlant resources easy to use in class settings
  • easy to work with ad-hoc user groups (workshops, tutorial with ease of provisioning/deprovisioning) especially for institutions with poor IdM
  • integration with LMS
  • integration with dashboard for management of self-paced tutorials/learning material
    

Outputs of iPlant

• toolkit for providers integrating with iPlant (iPlant does the heavy lifting with InCommon and others)
• toolkits for developers (domestication info; different toolkits for different needs and varying levels of sophistication)
• SSO features/capabilities for end consumers
• best practices for community (most resource providers have no idea about federation, domestication, VO IdM)
• a few domesticated apps
• infrastructure that promotes better collaboration
  • environments can be provided to researchers to give them a place to build their tools (they are designing the instructions and components for doing this; it will be platform independent)

Key applications needing domestication

• iRODS
• VNC
• others?
• iPlant current offerings
  

• misc notes
  • is there a flow diagram of all the ways researchers can access iPlant services? No, but this may be something the Bedrock grant-funded person may be assigned as an "intro" project; this basically will help understand scope
  • by end of meeting, that grant-funded position will be better scoped and hiring process can start
  • some time estimates for some of the work and priorities for iPlant would also be helpful, so we can determine where we need to wait to see how a space

—

Interactive presentation by Scott Koranda wrt my.ligo.org

—

iRODS

supports local database store for username/passwd, supports kerb, supports GSI; download as source code and compile and if you're using one of the listed forms of authentication, you are good to go from there; users can access via command line, webclient (webdav); API will be available through iPlant that will make iRODS accessible to the community; you can decide with whom you want to share a file, so with COmanage, knowing the membership of how you are sharing, what you are sharing, would be an important part of the service offering; ability to sync data is a really big thing (iDrop) because of how data will move from one repository to another transparent to the apps and the users; in terms of sharing and permissions, iRODS supports UNIX-like permissions; user and community data both is stored in iRODS, making it both a data store and a content delivery system

• check out DOI as a concept that links data, service, identity for publication
• not sure that COmanage itself can really help with the iRODS work; perhaps in making sure that information is expressed in a way the iRODS API can attach/consume?
• is iRODS a candidate for Moonshot?

—

Interactive presentation by Benn Oshrin wrt COmanage mockups

—