Session Management Use Cases

Typical Use Cases

1. Create a New Session Remotely

User launches Eclipse on their workstation. Eclipse launches a resource manager proxy by establishing an ssh connection to a remote machine and executing the proxy. The proxy "starts a new session" with the STCI in a manner defined by the infrastructure lifecycle WG. The proxy receives monitoring information from the STCI and forwards to Eclipse. When the user wishes to run an application, the proxy informs the STCI which requests a resource allocation and launches the application. Similarly for a debug and/or performance analysis activity. When the user exits from Eclipse, the proxy is instructed to "end the session" with the STCI, terminate, and the ssh connection is closed.

In this scenario, I would view an STCI session as beginning from the "starts a new session" and ending with "end the session". Since we agreed that the STCI would support two modes of operation (persistence and single instance), I would envision "starts a new session" meaning that the proxy would check for an existing STCI and establish a connection to it in some manner, or start the STCI and then connect to it, possibly depending on user preferences.

2. Connect to, Disconnect From and Reconnect to a Session - A

User starts TotalView on the head node of a cluster. TotalView checks for an existing STCI, finds one, and connects to it. The user then requests a debug session using all nodes on the cluster. The STCI requests an allocation from the job scheduler, LSF, but some of the nodes are currently in use. The job is queued, and the user is informed of an anticipated start time in 5 hours. The user exits from TotalView, which disconnects from the STCI, having first saved the session ID. 5 hours later, the user receives an email that their job has started and they have 5 minutes to connect before the job will be terminated. They launch TotalView, which reconnects to the STCI using the same session ID, and then establishes a debug session with the running processes. When the debugging is completed, TotalView exits and discards the session ID.

In this scenario, I've introduced the notion of a "session ID" to preserve state across "connections" to the STCI. Here I see a "session" as being the lifetime of a "session ID". i.e. as long as the session ID is still valid. I would imagine the API has the notion that starting/ending a session is distinct from disconnecting/ reconnection to a session.

3. Connect to, Disconnect From and Reconnect to a Session - B

A slight variation on (2) might be as follows. User starts Open|SpeedShop which attaches to an existing STCI. The user launches an experiment to capture and report profiling information. The user knows that the application takes 24 hours to complete, so they instruct OSS to disconnect from the STCI, saving the session ID. The next day they start OSS which reconnects to the STCI using the session ID, gathers the profiling information and displays it to the user. The user then terminates the session.

4. Concurrent Sessions

User uses OpenSpeedShop to attach to an existing STCI session as described in (3). The user launches an application with a 2 hour runtime and disconnects from the STCI, collecting a session ID. The user then uses OSS to create a new STCI/Session and launch another application. The user disconnects from the second session, collecting its ID. He then reconnects to the first session to check on the initial application's progress.

5. Multiple Connections To One Session (Incomplete)

User connects to an existing STCI session via Eclipse on their workstation to monitor a running process. User goes home without shutting down Eclipse or disconnection the session. User connects to the same session to monitor the job's progress from their laptop.

  • User's connection attempt is rejected?
  • User connects but the connection on user's workstation is disconnected?
  • User connects and the connection on user's workstation remains valid?

Alternatively: To help prevent this case the user's workstation's session access was disconnected automatically after N minutes of inactivity, returning a session ID for reconnection later.

Hypothetical Use Cases

The utility of behavior described in these use cases is in question. They are outside the core functionality of session management considered at the initial STCI meeting. Further consideration of implementation details is contingent on approval by the working group.

6. Multiple Users Access One Session

User Bob uses OpenSpeedShop to attach to an existing STCI session as described in (3). Bob launches an application with a 24 hour runtime and disconnects from the STCI via OSS, collecting a session ID. Bob gives his session ID to user Alice who, 24 hours later, launches OSS from her own account and connects to the STCI using Bob's session ID. She gathers and displays the performance data and terminates the session.

7. Credentials Prevent Unauthorized Session Access

User Bob uses OpenSpeedShop to attach to an existing STCI session as described in (3). Bob launches an application with a 24 hour runtime and disconnects from the STCI via OSS, collecting a session ID. Carol steals Bob's session ID. She launches OSS from her account and tries to connect to the STCI with Bob's session ID, but can not because she is not on a list of users permitted to access this session.

8. Multiple Users Access One Session Simultaneously

User Bob uses Eclipse to launch an application through the STCI as in (1). While the application is running Bob obtains the session ID and gives it to Alice who launches Eclipse and uses it to connect to the STCI session via an ssh connection to her own account on the remote machine. Bob and Alice monitor the progress of the job at the same time, but Alice's access to agents and commands that affect the job's progress are restricted. She is a 'read-only' user of the session.

Cases 7 and 8 introduce the idea of user-lists associated with individual sessions and with user permissions associated with agents within a session. Restricting agent access might only be necessary if multiple users could connect to one session at the same time, to prevent conflicting operations. These ideas only make sense if distinct users are capable of accessing the same session in the first place.

Use Cases 1-3: Greg Watson
Use Case 4-8: Wyatt Spear

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License