SDS@hd/SV Management New

This page is still in preparation.

For (previous) users of the SDS@hd Management Tool:

We've replaced the SDS@hd Management website with the bwServices Management website. The main changes in the registration and management process are as follows: An SV must be a part of a bwServices-Project. An SV is an Allocation requested from the Resource SDS@hd. The SVV role was removed. SVVs are now the PI (Principal Investigator) of a bwServices-Project that contains the SV. The SV-Manager role was removed. Managers (PMs) can be assigned within the project and have mostly the same rights as the PI. Publications can be added to the project at any time. New SV members can directly be added by one of the PMs. There is no need for sharing an SV-password and filling in a collaboration form anymore.

This page provides an overview of options to structure projects that use SDS@hd. The simple use case is:

• One research project has one bwServices-Management Project.
• One bwServices-Management Project has one SV.
• Both have the same group of members.

The graphic below visualizes one option for another setup. Depending on your preferences of who should have access to which data, you can structure things differently.

A Project consists of multiple elements like a description, users and allocations/SVs. Every user in the project can be added to one or multiple of the available SVs.

bwServices Management

In bwServices Management the top level entity is a project. On this page 'project' always refers to this bwServices-project. Every bwIDM member with employee status can create a project by going to the Projects page (Home -> Projects) and then clicking on the "Add a project" button. A project can have multiple users. For specifics regarding the different roles in a project see the Roles section.

The start page lists recent projects and allocations. The titles link to the complete lists.

Adding users to a project: On the project's page either the button on the top or next to the users list can be used for adding users. Users that already logged in to the bwServices Management page once, can be found via their user id. Aternatively, users can be sent an invite link via their email address. The email address for sending the invite doesn't need to be the address that is later on used for their account on bwServices Management. When a user clicks on the invite link they have to login to bwServices Management. Afterwards they are a part of the project with the account that they logged in with.

A project can have multiple allocations. Having an allocation means that you can allocate a resource like SDS@hd for your project. An allocation comes with its own form to fill in and its own terms to agree to. You can find detailed instructions under Registration/Apply for new SV.

Adding users to an allocation:

An allocation can have multiple users. The users can be chosen from the list of project members.

Here is an overview of the most important pages and what you can find there:

Roles in a Project

There are three different roles in a project. Depending on the role, different management activites can be executed at bwServices Management. These are described below. They include top level management of user access.

User

Users can...

• ...view project information.
• ...view allocations that they are a member of.

• ...enable/disable notifications. Notifications regarding the Projects or SVs that they are a member of can be:
  • E-Mails from one of the project's PMs
  • information about having been added to an allocation.
  • information about accepted or denied change requests.
  • information about a project being archived.
  • information about an allocation being activated or denied.

Project Manager (PM)

Additionally to the abilities of a User, a PM can...

• ...add and remove Users from the project.
• ...add and remove Users from allocations.
• ...change the roles of Users on project and allocation level (Project: User <-> PM; SV: None <-> Guest).

• ...enable/disable notifications for other Users.
• ...always receive email notifications.
• ...write an email to all Project Users.

• ...request new allocations.
• ...change project attributes.
• ...add publications.
• ...extend project lifetime.
• ...extend allocation lifetime.

Yearly Project Extension

Once a year the PI or a PM in the project needs to apply for a lifetime extension. This is indicated by the label "Project Review". Please update your project information first before applying for the extension. Especially, update the list of publications for which the allocated resources (e.g. SDS@hd) were used.

Principal Investigator (PI)

A PI is automatically a PM as well. -> Mentions of 'PM' always include the PI. Additionally to the abilities of a PM, the PI...

• ...is responsible for the whole project. This includes all allocations, independently of who requested them.
• ...is automatically a member of every allocation.
• ...can archive (~delete) the project.

Archiving a Project

Caution: Same as deleting all allocations! For project owners there is a button for archiving the project in the upper right part of the project page. Archiving means that the status of the allocations changes to "expired" and thedeprovisioning process starts. The project with its description will be deprovisioned some time after all allocations are removed.

Roles in a SV

The SV users keep their project roles (PI/PM/User). Additionally, they can hold the Guest role in an SV. The roles within the context of an SV are described below.

All SV Users

At bwServices Management they can...

• ...view their role in the SV. If no Role column is shown, there are no users with a Guest role in the SV.
• ...view the status of the SV (active/expired, end date)

Guests

PMs can add the "Guest" role to a user in the SV by going to the users list of the allocation and clicking the pencil button in the last column of the user's row. This leads to the details of the user where the role can be changed. As soon as the first user is defined as Guest via bwServices Management, a "guest" folder is created in the SV. A Guest can see but not access content in the SV root. They can only work within the "guest" folder. For more information see Guest Folder. Caution: When adding new guests to the Project and afterwards to the SV, make sure to directly change their role in the SV from the default to "Guest". Otherwise they have full access first.

PMs

PMs in the project can manage the SV as mentioned in their role description.

Adjust SV Attributes

To change the properties of your SV, you can hand in a Change Request. When you request a quota expansion for your SV at the SDS@hd service in order to store hot scientific data, we kindly ask you to answer the questions in the justification textfield for reasoning the extension.

Please also consider the following remarks: Upon increasing storage capacities, there will also be a need for further activities in the reporting from your side, e.g. by pointing out the usage of SDS@hd in scientific publications to us. More information about this can be found here: https://wiki.bwhpc.de/e/SDS@hd/Acknowledgement Please consider raising funds for the usage and further operation of the SDS@hd service. We will gladly support you with this.

Yearly SV Extension

Once a year a PM in the SV needs to apply for a lifetime extension of the storage project. This is indicated by the label "Allocation Renewal". As long as SDS@hd is used appropriately, an extension will be granted. Warning: You have to apply for the extension in the given timeframe. When you're too late, you have to contact the sds-support to get the extension. SVs that don't get extended, are going to be deleted by us, see SV Deprovisioning. Before the deletion, the PI is informed via email.

SV Deprovisioning

The deprovisioning is initiated in the following cases:

• The SV is not extended.
• The Project was archived.
• A PM that is a member of the SV asks via Change Request (comment in the description field) for a deletion of the SV.

The deprovisioning basically contains the following steps:

• The access of the SV-group to the SV is blocked. The access to any data that is saved within the SV is not possible anymore.
• After a specific period of time all data in the SV gets permanently deleted.

FAQ

• Is there a Test-SV to do technical tests?

  Yes, there is a Test-SV for this purpose. You can write to the support to get invited. Please keep in mind that data gets regularly deleted and users may be removed after some time.

• How can I remove myself from an allocation or project?

  This is not possible. You must ask a PM to remove you.

• How can I deactivate Users?

  Users can't be deactivated. They can only be removed from allocations or projects.

• My project or my allocation ist expired. How can I prolong it?

  Please submit a Ticket

• How can the PI of a project be changed?

  This is currently not possible but will be possible in the future.

• I changed a user's role in bwServices Management but the user still has the previous access rights.

  After 30 minutes the adjustment should be synced to all systems. If not, it helps when the member with the role change logs in to bwServices once to trigger an automatic update and then waits for 30 minutes.

Within the SV

While bwServices-Management manages the access rights and storage amount on a top level outside of the storage space itself, there are multiple options to organize data and adjust access rights when being connected to the SV.

Default Access Rights

• In the main space of an SV everyone has read and write access.
• The person who creates a file or folder is the owner. The owner can adjust the rights via [[Workspace#Regular_Unix_Permissions | chmod].
• The SV responsible has full control over the access rights by being able to take ownership of files.
• The SDS@hd support can help with defining access rules for your specific use case. Optimally, this is discussed before the SV gets filled with data. Examples:
  • A group folder with read only access in contrast to the default read and write access. The SV members can see everything from each other but not change files that aren't their own.
  • A users folder where every user can create their own folder with content that is inaccessible to others.

As an example, let's assume that the SV is structured as shown in the graphic below.

In the SV scheme on the left you can see that the SV has two guests, two full members and the PI. The full members have read and write access to all normal folders in the SV root and the `guest` folder.

Additionally, there can be a `users` folder with a special setup. In the `users` folder everyone has read access but only the owners of the folders/files have write access. Hint: If needed, the SDS@hd support can create custom access rules for specific top level folders.

The SV scheme on the right visualizes how the orange full member experiences the access when working in the SV. The full member has free read and write access to everything except the personal folder of the blue user.

Guest Folder

Using the option to add some SV members with the role "Guest" allows better access management for separate user groups that shall not get access to the whole SV.

Use Cases:

• Data exchange with core facilities.
• Projects together with external collaborators.
• Up- and Download area

Setup:

• PMs can enable the guest folder by adding guests to the SV see Guests. The folder gets created as soon as the first Guest user is defined. The creation might need up to 20 minutes.

Access Rights

• Full SV member:
  • Read and write access to all content of the SV including the guest folder.
  • No access to content that was deliberately made unaccessible by other SV members via chmod.
  • No access to 'user folders'.
• Guest:
  • Folder above guest folder:
    • Can see all file and folder names. Can't see content in subfolders.
    • Can't access or create content.
  • Guest folder:
    • Can only create folders, no files, in the root of the guest folder.
    • Read content. Read content in subfolders.
      • Alternative setup: Read content. Can't read content in subfolders / folders from other guests. Please contact the sds-support to get this setup.
    • Has only write access to content that they created themselves.

The following graphic shows the current default access rights in the guest folder on the left in contrast to the alternative setup on the right.

Storage Space Management

At the moment you can't see how much storage space is left. We are working on including this information.

To keep the data hot, you should regularly check the following points:

• Make sure that temporary data gets removed.
• Make sure that no data from finished projects is stored. You might want to archive those with one of the archiving services listed on the Main Page.
• If someone has left the storage project, make sure that the PI has access to the data and the data is still hot.