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 "OwnerCO". 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 OwnerCO. 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 OwnerCO 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 OwnerCO 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 OwnerCO 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 OwnerCO is sent to a developer who submitted the request. If the request is approved, the requesting CO 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 OwnerCO 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 CO list.
Public sharing of components
Components are not shared “on request”. For a component the OwnerCO can choose to make the component "public”.
This means that developers in any CO 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 and you cannot remove access to specific COs. 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 COs 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 CO.
This creates a mutual chain of responsibility and trust between COs.
Alternatively, a developer of the receiving CO might also be invited to the OwnerCO 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 OwnerCO.
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 COs 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 COs 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 OwnerCO to that Golang component.
Other researchers also want to use that component in their catalog items and invite her to join their respective CO "B" as a developer.
She accepts the invitation to CO B. Now she can allow their CO B to CO A's Golang component.
More specifically, she can now add CO B to the list "Allowed COs" in the Golang component.
Minimal necessary scope for COs
COs 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 CO, think about its purpose in terms of sharing.
For instance, you might want to have specific COs 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 CO when the item is relevant to all the CO's members.
If the catalog item or the component is not relevant to all members, a new CO with a subset of the members should be considered.
Continuity
To allow for continued support, each CO should have at least two users who are also developers in that CO.
Their memberships in other COs should intersect such that they both can maintain the "Allowed COs" lists of all the catalog items and the components that are owned by the CO.
Four Eyes Principle
Within a CO, you can enforce the four eyes principle. This might be handy for long-lived COs that depend on several catalog items and components of other COs.
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 CO 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.