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
- Reporting
- need some more requirements - are these reports purely IdM? Are they querying the apps? Are they usage reports for the platform?
- iPlant has social scientists on board who want to have reports on who/what is working with whom, probably more
- History
- keeping information is important, but keeping it private is also important; iPlant needs to consider what they'll need in workgroup situations
- Details/Questions
- Is everything being stored in LDAP or some other way? Current implementation is built on top of a database (currently postgres, but that's adjustable); the registry piece should, in the long-term, be considered a black box - the VO shouldn't have to worry about this; the applications themselves will be looking at an LDAP or getting exposed to SPML
- How much of this is exposed to API-style calls? Yes, most of the code is RESTful; everything that is documented on the wiki is implemented
—
For tomorrow, make sure we cover what tokens are used by what app, via COmanage; what are the best practices here
Detailed use cases
iPlant's enrollment process (today) http://www.iplantcollaborative.org
- enrollment is based on users wanting access to apps; they learn about the discovery environment through word of mouth;
- discovery environment and My.iPlant - they request access via website form, based on form that TeraGrid uses; notice then goes to a person who will run the scripts to create an account; backend is mostly a manual process at this point; they have a suite of python scripts that create accounts in LDAP and in the apps that need local accounts (i.e. JIRA); scripts also send out notifications to users letting them know account has been created and what their password is
- DNASubway has a different process for enrollment, they do not have an LDAP, different forms; but the account creation is automatic
- it would be desirable to be able to delegate the invite process to appropriate managers, and not core staff
- the information that is requested in part feeds the reports in to NSF, so we may need to define what items are actually required
iPlant's enrollment process (proposed)
- will be done in Python/Jango
- this will be a centralized place to mange app services, api, and personal information; the registration process itself is not likely to change (much)
- apps will be both iPlant apps and Community apps
- allocations will be viewable (how much storage and where, how much resources (CPU, Memory, Block storage) in "Atmosphere", how much time in HPC; can also request larger allocations; they have the capabilities for some of this already
- still to do: systems access, including Atmosphere and virtual hosting, communications sections (users managing their own lists through this portal), group management (creating groups, verifying membership), HPC-related integration