Sharing Catalog Items
Collaborations on SRAM are the way that SURF supports collaboration among researchers. Please refer to the chapter Working Together of the Research Cloud docs to learn how to create and administrate collaborations.
A collaboration consists of one or more admin members and other invited members from different institutions. In Research Cloud, particularly, a collaboration can also have members with a "developer" status. Developers are granted special rights that enable them to create, maintain, and share Research Cloud components and catalog items with other collaborations.
Each component and catalog item has an "owner collaboration". This is the collaboration that created the component or the catalog item. The responsibility to maintain and repair a given component or catalog item is with the developers of the owner collaboration. They take care that the component or the catalog item works as expected and is shared only with other collaborations that are entitled to it.
Catalog items on request
Catalog items can be shared with other collaborative organizations on request. This is determined by the developer of a catalog item and indicated by ticking the box “On request” in the 4th step of the catalog item creation wizard.
If a catalog item can be requested it is marked with a lock icon and can be requested by a developer of any other collaboration. Catalog items “on request” are visible to all collaborations in SURF Research Cloud.
To request a catalog item, a user with developer’s rights clicks on the request button and fills in a message box. The message will be shared with a developer from the owner collaboration of a catalog item, therefore it should contain a meaningful text that explains why a catalog item is requested.
After the request is sent, a developer in the owner collaboration gets a notification about the request. The notifications can be seen in the “requests” menu (lock icon) in the upper right corner of the portal.
A developer of the owner collaboration can review the request and choose whether to approve or deny it. The approval/denial decision can be accompanied by a message to the requestor. After that, a notification with a decision from the owner collaboration is sent to a developer who submitted the request. If the request is approved, the requesting collaboration can start using the catalog item right away.
The Requests menu allows any developer to overview and manage all their sent or received requests.
A developer from the owner collaboration can also terminate the usage of a requested catalog item. This can be done by editing a catalog item and removing collaborations from the allowed collaboration list.
Public sharing of components
Components are not shared “on request”. For a component, the owner collaboration can choose to make the component "public”.
This means that developers in any collaboration can use the component in their catalog item.
Once a developer gets access to use a component, they can use it in a catalog item. If component access would be restricted later, this means the catalog item won't function anymore. Therefore, we don't allow component access to be withdrawn at a later time. You cannot remove "public" access from a component. You cannot remove access to specific collaborations. If this causes problems, you can contact the service desk for help.
Private sharing of components and catalog items
Components and catalog items can also be shared privately. To make the agreement on usage and maintenance explicit and personal, a developer can only share a component or a catalog item with collaborations that s/he is also a developer-member of.
Thus, a developer of the offering CO must have been explicitly made a developer-member of the receiving collaboration.
This creates a mutual chain of responsibility and trust between collaborations.
Alternatively, a developer of the receiving CO might also be invited to the owner collaboration instead of vice versa.
This also enables sharing and makes sense when the developer is going to help with supporting the components and the catalog items of the owner collaboration.
Examples and Best Practices
Requesting catalog items
Example:
A researcher has created a catalog item. It is a composition of several components to form a specific data processing pipeline. A researcher thinks that the catalog item may be of use to other researchers on SURF Research Cloud and makes it available “On request”.
The colleagues from different collaborations can request the catalog item from a researcher who developed it by clicking on the “Request” button.
The developer of a catalog item approves the request and the colleagues from different collaborations can now use the catalog items.
Private sharing of components and catalog items
Example:
A researcher is a developer in her CO called "A". She has created a component that installs Golang on a Linux system. "A" is the owner collaboration to that Golang component.
Other researchers also want to use that component in their catalog items and invite her to join their respective collaboration "B" as a developer.
She accepts the invitation to collaboration B. Now she can allow their collaboration B to collaboration A's Golang component.
More specifically, she can now add collaboration B to the list "Allowed collaborations" in the Golang component.
Minimal necessary scope for collaborations
Collaborations are easy to create and administrate. Generally, it is a good idea to keep them as small and as short-lived as possible.
When creating a collaboration, think about its purpose in terms of sharing.
For instance, you might want to have specific collaborations for requesting and sharing long-lived catalog items or other ones for experimenting with new components.
Also, as a general rule, a catalog item or a component should only be made accessible to a collaboration when the item is relevant to all the collaboration's members.
If the catalog item or the component is not relevant to all members, a new collaboration with a subset of the members should be considered.
Continuity
To allow for continued support, each collaboration should have at least two users who are also developers in that collaboration.
Their memberships in other collaborations should intersect such that they both can maintain the "Allowed collaborations" lists of all the catalog items and the components that are owned by the collaboration.
Four Eyes Principle
Within a collaboration, you can enforce the four eyes principle. This might be handy for long-lived collaborations that depend on several catalog items and components of other collaborations.
If you make sure that no admin member is at the same time a developer, the "invite and share" process remains transparent among the responsible collaboration members:
the developer has to communicate with the admin for invitations, and the admin has to communicate with the developer for sharing components and catalog items.