Form to request CSA and expected workflow

7 posts / 0 new

Log in to post comments

Fri, 2019-06-14 11:00

#1

It looks like the expectation of requesting a CSA area, is by sending a help email. How about putting a form on the RSP instead that way we can be sure to collect all relevant fields needed such as support contacts, documentation, etc.? The form could pull the information from RDR on where CSAs are supported and enable the user to select multiple. On the backend, a ticket can be created to track the request. The CSA owner should then be able to update that entry whenever needed.

In the event a CSA owners wants an area on multiple resources, who owns the ticket and helps follow thru with it at each site?

In general, I would suggest adding a description of the expected workflow CSA owners go thru to request, get, and manage CSA areas and any responsibilities as far as documentation, registering, etc.

Fri, 2019-06-14 11:11

#2

Shava Smallen

Along the same lines, is there any vetting of CSA requests? I.e., to make sure it's just a library or tool rather than a service.

Fri, 2019-06-14 15:09

(Reply to #2) #3

John-Paul Navarro

Under "E.1. Expectations and Dependencies" I've added the statement indicating the CSA owners should:

Not run persistent services using CSA software, though CSA software may include software that can be run as a service inside batch jobs

Fri, 2019-06-14 15:29

#4

John-Paul Navarro

Using the RSP to facilitate submitting CSA requests is an interesting idea. For now I would prefer to keep the implementation simpler by including the following instructions in the XUP's CSA user documentation page. Note that this page will already lists which resources support CSAs:

Submit a single request to define a "CSA support contact" only if they intend to publish software modules. Include in that request the "Name of the support organization" and one or more of "support e-mail", "support phone number", and/or "support web page"
Submit separate CSA request tickets for each resource where a CSA is desired with the following: associated allocation ID, CSA name (something short that could be used as a directory name and a unix group name), CSA owner XSEDE username, and XSEDE usernames of any other users that should have CSA write ability (to be implemented using unix group permissions).

How about we record this automation improvement idea in JIRA for future consideration?

Thanks,

JP

Mon, 2019-06-17 22:13

(Reply to #4) #5

Shava Smallen

I agree, doing this as a future enhancement would be fine and maybe once we get feedback from a few CSA owners who have gone thru the process.

Fri, 2019-06-14 16:43

#6

John-Paul Navarro

There is a new CSA request process workflow in "F. System Architecture and Detailed Design" showing how the CSA owner, XSEDE, and Service Provider(s) interact to request, create, publish, and discover CSA software.

Thanks for suggesting we document the workflow. Very useful!

Mon, 2019-06-17 22:12

(Reply to #6) #7

Shava Smallen

Thanks JP, that is helpful. Could you add a few steps as to the process of decommissioning a CSA for completeness.

Log in to post comments

ACCESS is an advanced computing and data resource supported by the National Science Foundation and made possible through these lead institutions and their partners:
Carnegie Mellon University, University of Colorado Boulder, University of Illinois at Urbana-Champaign, and State University of New York at Buffalo .

Administrative Login

Search form

Form to request CSA and expected workflow