Update policies introducing maintenance policies (#249)

I provide an update of the policies as described in
[SRM-274](https://jira.cscs.ch/browse/SRM-274) in view of the
presentation "General Information for Users on Alps" at the UserLab Day
2025.

---------

Co-authored-by: Luca Marsella <[email protected]>

Author: lucamar

docs/policies/index.md

@@ -6,7 +6,9 @@ The CSCS [code of conduct](code-of-conduct.md) outlines the responsibilities and
 
 The [User Regulations](regulations.md) define the basic guidelines for the usage of CSCS computing resources. The right to access CSCS resources may be revoked to whoever breaches any of the user regulations.
 
-## Computing Budget
+The [User Support Policies](support.md), the [Slack Code of Conduct](slack.md) and the [Scheduled Maintenance and System Unavailability Policies](maintenance.md) provide additional information on support services, the regulations of the Users Slack space and the scheduled maintenance events.
+
+## Resource Allocation Policies 
 
 Compute time on Alps systems is measured in node hours. Currently, we only support exclusive node allocations. This means that even if you utilize only a portion of a node’s resources (e.g., a single GPU), your account will still be charged for the entire node.
 
@@ -18,7 +20,7 @@ Please note that resources at CSCS are assigned over three-months windows
 
 ## Data Retention Policies
 
-Data belonging to active projects in the filesystems /users, /project, /store are under backup. There is no backup for data under the scratch filesystem, therefore no data recovery is possible in case of accidental loss or for data deleted due to the cleaning policy implemented on this filesystem.
+Data belonging to active projects in the filesystems `/users` and `/capstor/store` are under backup. There is no backup for data under the scratch filesystem, therefore no data recovery is possible in case of accidental loss or for data deleted due to the cleaning policy implemented on this filesystem.
 
 Please note that the long term storage service is granted as long as your project is active, and the data will be removed without further notice 3 months after the expiration of the project: please check the applicable filesystem policies for the grace period granted after the expiration of the project.
 

docs/policies/maintenance.md

@@ -0,0 +1,35 @@
+[](){#ref-maintenance}
+# Scheduled Maintenance and System Unavailability Policy
+
+To ensure the reliability and performance of the Alps production vClusters, CSCS continues to implement rolling updates aimed at reducing downtime during routine maintenance. However, regular interventions are still necessary at this stage.
+
+## Advance notice
+
+We strive to announce scheduled system unavailability at least one week in advance. In some cases, earlier notice may be possible, although this depends on external factors and internal approval processes.
+
+## Shared infrastructure
+
+Alps is a shared research infrastructure supporting a diverse range of research communities, partners, and projects. Occasionally, the system may be temporarily dedicated to specific scientific projects to enable large-scale capability runs.
+
+[](){#ref-maintenance-cadence}
+## Maintenance and availability cadence
+
+To help users plan their activities within each allocation quarter, we provide a tentative schedule of system unavailability. Please note that this schedule is subject to change based on operational requirements:
+
+### Routine maintenance
+ * __Cadence__: Occurs weekly, depending on need
+ * __Typical duration__: Half a day; occasionally up to one full day
+
+
+### Extraordinary maintenance
+ * __Cadence__: At least once per quarter
+ * __Typical duration__: Two days; may be extended if necessary
+
+### Dedicated large-scale capability runs of scientific projects
+ * __Cadence__: At most once per quarter
+ * __Typical duration__: One week
+
+[](){#ref-maintenance-feedback}
+## Communication and feedback
+
+CSCS values the constructive feedback provided by users. We will use this input to enhance our communication practices and to develop mitigation strategies for scheduled events that may significantly impact system usability.

docs/policies/support.md

@@ -1,13 +1,11 @@
 [](){#ref-support}
-# User Support Policy
-
-## 1. User Support Policy
+# User Support Policies
 
 CSCS operates an advanced research infrastructure dedicated to High-Performance Computing (HPC) and other scientific applications.
 Our infrastructure encompasses a wide array of resources including compute, network, supporting software and tools, and several software applications used by a broad user base.
-Our user support policy outlines the level of assistance users can expect, the types of support offered, and the guidelines for requesting and receiving assistance.
+Our user support policies outline the level of assistance users can expect, the types of support offered, and the guidelines for requesting and receiving assistance.
 
-## 2. Best Effort Support
+## Best Effort Support
 
 CSCS is committed to offering best effort support to our users.
 Our goal is to provide responsive and effective assistance, ensuring the hardware and software infrastructure operates at a high level to satisfy the majority of the scientific community’s needs.
@@ -25,7 +23,7 @@ Support will be focused on ensuring that the resources are used in alignment wit
 Requests that significantly deviate from the original proposal may not be accommodated.
 
 [](){#ref-support-user-apps}
-## 3. User Applications
+## User Applications
 
 User applications are those brought to CSCS systems by the users, whether they are developed by the users themselves or another third-party.
 Packages or applications not provided by CSCS are considered user applications.
@@ -35,7 +33,7 @@ While we can assist with infrastructure-related issues, we can not configure, op
 Users are responsible for resolving application-specific issues themselves or contacting the respective developers.
 
 [](){#ref-support-apps}
-## 4. Officially Supported Applications
+## Officially Supported Applications
 
 CSCS offers a range of officially supported applications and their respective versions and configurations, which are packaged and released by CSCS or its supply partners.
 These packages benefit from our resources, expertise, and comprehensive documentation.
@@ -46,33 +44,32 @@ This support also extends to common tools and libraries provided by CSCS for the
 While CSCS provides enhanced support for third-party software included in our officially supported applications, our ability to resolve issues is contingent on the extent of our expertise and control.
 Bugs or other problems that fall outside of our immediate control will be escalated to the relevant third-party vendors, but further resolution will depend on their response and capabilities, limiting our ability to fully address such issues.
 
-## 5. Prioritisation Criteria
+## Prioritisation Criteria
 
 Support cases will be prioritised based on factors such as the impact on CSCS's overall mission and services, potential for knowledge transfer, degree of expertise required, and time and effort required to provide support.
 Issues directly concerning products and services offered by CSCS will be given higher priority.
 
-## 6. Collaborative Support
+## Collaborative Support
 
 The effectiveness and efficiency of our support are greatly enhanced when users work collaboratively with us. By providing thorough information users enable us to deliver more effective and timely assistance. To facilitate effective support, users are expected to:
 
 * *Consult Documentation*: Users are encouraged to review the provided documentation and indicate what they have consulted before seeking support.
 * *Provide Detailed Information*: Users should offer, to the best of their ability, sufficient documentation and information about their software and the issues they are experiencing.
     This includes detailing previous attempts to resolve the issue and any relevant error messages or logs. Clear and precise communication of the problem and steps already taken helps us diagnose and address issues more efficiently.
 
-## 7. Closure of Support Tickets
+## Closure of Support Tickets
 
 Support tickets related to user applications will be closed if, after providing all feasible guidance and troubleshooting within our support scope and capacity, it is determined that the issue lies beyond the control of CSCS, such as in the user’s application code or third-party dependencies.
 In such cases, the ticket will be closed after the user has been informed of the situation and provided with any relevant recommendations or resources for further investigation.
 Users are welcome to reopen the ticket if new, actionable information becomes available.
 
-## 8. Communication Channels
+## Communication Channels
 
 Users can request support through the CSCS Service Desk. Updates and communication with support staff will be provided through e-mail or via the Service Desk. Users are also encouraged to communicate with each other via our community channels. CSCS reserves the right to make other forms of communication also available.
 
-## 9. Continuous Improvement
+## Continuous Improvement
 
 We are committed to continuously improving our support services.
 Feedback from users is welcomed and will be used to refine our support policies and procedures to better meet the needs of our community.
 
 By adhering to this user support policy, we aim to ensure a consistent and satisfactory support experience for all users at CSCS.
-

mkdocs.yml

@@ -141,8 +141,9 @@ nav:
     - policies/index.md
     - 'User Regulations': policies/regulations.md
     - 'Code of Conduct': policies/code-of-conduct.md
-    - 'UserLab Support Policy': policies/support.md
+    - 'User Support Policies': policies/support.md
     - 'Slack Code of Conduct': policies/slack.md
+    - 'Scheduled Maintenance and System Unavailability Policies': policies/maintenance.md
   - 'Contributing':
     - contributing/index.md