On-RAMPS Use Cases

OR01: New HPC researcher looking for a resource to fit their research needs

Summary

A researcher without previous HPC experience desires to begin using HPC for their research. They have a vague idea that they need to find a resource to use, but aren’t well-informed about ACCESS, and don’t know what resource they might need.

They should be able to navigate to their local On-Ramps interface, learn about various ACCESS and local resources, and be guided in understanding what options are available and what they might want to use.

Status

Proposed: Resource Catalog allows for campus resource connections, wrap up with the “what is ACCESS” content. Need a deployable package that the campus can link to from their webpage. Finding sites who want to host this. Having staff who can help.

Actors

New researchers interested in using HPC

Researcher User Experience:

• Researcher navigates to local site’s HPC portal, and follows a link to the On-Ramps interface.

• The researcher is presented with a newcomer-friendly interface that explains the various resources available, and explains the process for requesting and getting an allocation.

• Within this page, the researcher can explore the resource list, being provided with guidance about which resources might be useful for their area of research, and descriptions of the difference between local and ACCESS resources. Local resources should be presented first in the list, or in a position of prominence

• After exploring the list, the researcher should have an adequate understanding of what resources are available, whether they are local or ACCESS, and what the next steps would be to request an allocation on them.

• The researcher will be presented with information about how the ACCESS Credit marketplace works, so that they understand that if they make a request for ACCESS resources, that means they are requesting credits that will be exchanged for resource time, as opposed to directly requesting access for a resource.

• Instructions for getting help should be provided to the researcher, with clear indicators of where to get ACCESS support, so that support requests for ACCESS don’t get sent to the local site support staff.

Success Criteria

At the conclusion of this use case, the researcher should be aware of what resources are available, have adequate information and direction in selecting one, and be ready to make an HPC allocation request, should they so desire (leading into use case OR03 or OR04)

OR02: Site-local established researcher looking for more resource options

Summary

A researcher with previous HPC experience is looking to expand their HPC use, and wants to find additional resources beyond what they have used at their local institution. They may have heard about ACCESS, but do not yet have a user account or allocation on ACCESS.

They should be able to navigate to their local On-Ramps interface, and easily discover what ACCESS resources may be available to them, being able to filter or search for resources with certain characteristics that may be of benefit to their research. They will also be provided guidance about how the ACCESS allocations process will work.

Status

Proposed

Helpful text for established researcher. Figure out where they would enter information and how it would be pulled into widget

Actors

Established researchers desiring to expand their HPC usage.

Researcher User Experience:

• Researcher navigates to local site’s HPC portal, and follows a link to the On-Ramps interface.

• The researcher is presented with a newcomer-friendly interface that explains the various resources available, and explains how the process of getting an ACCESS allocation will be different than requesting a local allocation.

• Within this page, the researcher can explore the resource list, being provided with tools such as filtering, searching, etc, to identify resources that would be good fits for the specific research being done.

• After exploring the list, the researcher should have an adequate understanding of what resources are available, whether they are local or ACCESS, and what the next steps would be to request an allocation on them. Local resources should be presented first in the list, or in a position of prominence.

• The researcher will be presented with information about how the ACCESS Credit marketplace works, so that they understand that if they make a request for ACCESS resources, that means they are requesting credits that will be exchanged for resource time, as opposed to directly requesting access for a resource.

• Instructions for getting help should be provided to the researcher, with clear indicators of where to get ACCESS support, so that support requests for ACCESS don’t get sent to the local site support staff.

Success Criteria

At the conclusion of this use case, the researcher should be aware of what ACCESS resources are available, have adequate information and direction in selecting one, understand (in a high-level sense) how the ACCESS allocations process works. The would then be ready to make a request for an ACCESS allocation, should they so desire (leading into use case OR03 or OR04)

OR03: New-to-ACCESS researcher requests an allocation on an ACCESS resource

Summary

A researcher that has never been part of ACCESS wants to request an HPC allocation on an ACCESS resource. This could be the result of Use Case OR01 or OR02.

They should be able to navigate to their local On-Ramps interface, identify themselves with either an email address or a site-local authentication, and request an ACCESS allocation from the On-Ramps interface at their local site. At the end of making this request (or upon its approval), they should be smoothly directed into the next steps of getting integrated into the ACCESS ecosystem, and hopefully receive an approved allocation.

Status

Proposed

Minimal submit interface. Security implications.

Actors

Researcher who is making their first allocation request on ACCESS.

Researcher User Experience:

• Researcher navigates to local site’s HPC portal, and follows a link to the On-Ramps interface.

• The researcher will indicate (via a button or link) that they are ready to make an allocation request for ACCESS resources

• The researcher will either provide their email address, or potentially authenticate with the site’s local authentication service.

• The researcher will enter relevant information for their request (project summary, corresponding documentation, field of science, etc), and submit their request. This form will be a simplified form of the standard ACCESS request form, containing the minimum information needed to request an Explore allocation. The request will flow into the standard ACCESS allocations process.

• Upon submission, the researcher will receive adequate information (Via confirmation page and email) of the process and next steps for exchanging their credits.

Success Criteria

At the conclusion of this use case, the researcher should have successfully made an ACCESS allocation request through On-Ramps, and have been provided with documentation about next-steps in the process.

OR04: New researcher decides to make a request for a site-local resource

Summary

A researcher desires to request an allocation on a site’s local resources. This could be the result of Use Case OR01.

They should be able to navigate to their local On-Ramps interface, identify themselves with either an email address or a site-local authentication, and request a local allocation from the On-Ramps interface at their local site. At the end of making this request, their request should be forwarded to the site’s local allocations process, and the user will be informed of the next steps for the local allocations process.

Status

Proposed. Related to 03

Actors

Researcher who is making an allocation request on their site’s local resources.

Researcher User Experience:

• Researcher navigates to local site’s HPC portal, and follows a link to the On-Ramps interface.

• The researcher will indicate (via a button or link) that they are ready to make an allocation request for local resources

• The researcher will either provide their email address, or potentially authenticate with the site’s local authentication service.

• Depending on the site’s local configuration, the user will either be forwarded to the site’s already-existing allocation form, or will be presented with the standard ACCESS allocation request form within the On-Ramps interface.

• If the researcher was forwarded to the existing allocations form, they will then follow the site’s allocations process at this point, outside the scope of On-Ramps.

• If the local configuration specifies that the On-Ramps allocation form will be used, the researcher will enter standard allocation request information (project summary, corresponding documentation, field of science, etc), and submit their request.

• Upon submission, the request will be automatically passed to the site’s local allocation process (either via API or by email)

• The requester will then be presented with both a web page explaining the next steps, and a confirmation email that explains the next steps of the process.

Success Criteria

At the conclusion of this use case, the researcher should have successfully made a site-local allocation request through On-Ramps, and have been provided with documentation about next-steps in the process.

OR05: Researcher with an awarded allocation wants to manage existing allocation

Summary

A researcher has an awarded allocation (continuing from OR03 or OR04 above) They arrive at On-Ramps wanting to manage their allocation.

Status

Proposed. Link to text from 01

Actors

Researcher who is already has an approved allocation on ACCESS or a site-local resource.

Researcher User Experience:

The researcher, upon arriving at the On-Ramps interface, will be shown a link for managing their ACCESS allocation. Following this link will take them to the allocation management page of the ACCESS allocations portal, where they can manage their allocation.

Success Criteria

At the conclusion of this use case, the researcher should have access to a web page allowing them to manage their allocation.

Appendix: suggested implementation notes

To support these use cases across a range of partner sites, it is suggested that the technical implementation allows for two areas of configuration choice between a simpler and a more advanced installation at the partner site.

Authentication

Integrating with a partner site’s local website integration is desired, but is technically non-trivial. In some cases, there is a desire to integrate the On-Ramps interface into a website that doesn’t have existing authentication. On-Ramps should include the ability to integrate in an anonymous mode, which requires researchers provide an email address with their initial request. The other option would allow for full integration with a site’s authentication system. As the On-Ramps interface is a front-end component, a system will need to be developed to ensure that it can validate the local authenticated user. The technical details are to be determined, but will likely be an integration with ColdFront’s authentication system.

Communicating requests for local partner resources

Partners have a range of mechanisms for requesting/creating/managing local resource allocations. On-Ramps should not require the partner to implement a complicated system for receiving these requests, if made through the on-ramps interface. As such, this mechanism should also have two configurable levels of integration. The first would be a simple email-based system: if a researcher makes a request for a site-local resource, On-Ramps/XRAS will simply email the request to a configured mailbox, so that it can be handled manually be the site.

For more advanced integrations, On-Ramps should be able to communicate with a ColdFront API.