Seqera Platform Feature Requests

As per ticket https://support.seqera.io/a/tickets/5683 , we would like Nextflow to support retrying of gRPC API failures. Recently, a patch was made to handle the "not found" error: https://github.com/nextflow-io/nextflow/commit/aa4d19cc1a56721b727eb6730a1cf4ee7c397049 . We would like the support for retrying gRPC for different failures: UNAVAILABLE, DEADLINE_EXCEEDED, RESOURCE_EXHARSTED, UNKNOWN etc

As a user, when configuring a Compute Environment (CE) on the Platform for Google Batch and opting to disable the use of external IPs for my VMs, I would like the CE configuration form to validate that a custom VPC and subnetwork are specified. Problem: Currently, if I enable the setting to disable external IPs without specifying a custom VPC and subnetwork, the Compute Environment can still be created. However, this misconfiguration causes pipelines to fail at runtime, requiring me to revisit and reconfigure the CE. This leads to unnecessary delays and a frustrating user experience. Proposed Solution: Add a validation step in the CE configuration form that ensures the following when disabling external IPs: A custom VPC is provided. A valid subnetwork within the custom VPC is specified. If these conditions are not met, the form should display a clear and actionable error message before allowing the CE to be saved.

We'd like to be able to turn those Emails off, or better filter them for the user.

Enhance the user experience by improving the widgets on the run detail page without altering user flows. The primary goals of this UI update are: Improve the entire page's layout by reorganizing the order of widgets and the information within them. Unify color and icon use to ensure consistency across the application. Specifically: To enhance the usability and aesthetics of the "General" widget in run detail page, improvements will involve reordering and resizing elements, optimizing the widget for increased interactive intuitiveness, unifying icon styles to outline format, and introducing an expand/collapse functionality. This aims to address the visual imbalance caused by the increased elements such as resource labels, pipeline name, and optimization details within the widget. The current Process widget layout presents problems because the names can be too long and unreadable, the numeric value is unclear, and the progress bar lacks clarity. We aim to improve this by resizing and restyling the Process widget, providing an easy way to jump into tasks, and evaluate an overall progress indicator for added clarity. Improve the Status widget UI on the run detail page, enhancing accessibility by adjusting text color contrast, consolidating the use of colors, especially for the "Cached" status, and renaming the widget to accurately reflect its content: "Task status." These changes aim to enhance user experience and clarity in interpreting the widget information. The Tasks table enhancement is addressed in a separate effort.

Is it possible to enable the estimated costs module for Azure Batch and AKS?

When Seqera Platform submits jobs to Azure Batch and encounters a 409 HTTP status code (indicating the batch quota limit has been reached), the run fails. Instead of failing, can we modify the behavior so that the platform continues attempting to submit the job until the Azure Batch pool can accept it? Caused by: Status code 409, { "odata.metadata":"https://babixanaldevm42aen.uaenorth.batch.azure.com/$metadata#Microsoft.Azure.Batch.Protocol.Entities.Container.errors/@Element", "code":"ActiveJobAndScheduleQuotaReached","message": { "lang":"en-US","value":"Active job and job schedule quota for the account has been reached.\nRequestId:e9dede46-9ab1-463b-b797-cdfee3d4db8f\nTime:2024-10-18T06:36:49.8081952Z" } } Instead of returning a 409 Status Code error and halting the run, Seqera Platform should retry submitting the job continuously until the quota is available, ensuring that the job is eventually accepted. This should be done without manual intervention and in a way that does not overload the system.

We would like to be able to authenticate to MySQL database with Microsoft EntraID due to security regulations. Entra ID Use Entra ID with MySQL database

Using public OpenID identity providers such as Google or GitHub to authenticate with Seqera Platform Enterprise is severely hampered by the inconvenient user management. While a user access allow-list can be used to restrict access to specific email addresses or domains, this list is currently only configurable via environment variables or the tower.yml configuration file ( https://docs.seqera.io/platform/24.1/enterprise/configuration/authentication#configure-user-access-allow-list ) As a result, any changes to the allowed users require administrative access to the server and a restart of the application. In large organizations like universities, the response times of central IT services are typically slow, making the onboarding of new users a process that can take weeks. For short-term users, such as interns or master’s students, gaining access is quite impractical or even impossible before their time at the organization ends. Therefore, it would be beneficial for organization owners on the Seqera Platform to have the ability to manage the allow-list directly through the user interface. Additionally, we have observed that the current allow-list functionality on the Seqera Platform can be too restrictive for users with multiple email addresses linked to their OpenID identity provider. For instance, we recently encountered a case where a user’s primary GitHub email was included in the allow-list, yet access was denied because their secondary email was not. If changes to the allow-list could be made quickly via Seqera Platform's user interface, this issue could have been resolved promptly. However, the weeks-long delay in implementing a change made it particularly frustrating that a user, whose primary GitHub email was already on the allow-list, still could not authenticate. Thank you for your understanding and implementation!

We're trying to track down an issue where our registered pipeline specs (specifically the git revision) are changing and we don't know why. I checked the audit logs, and they capture pipeline creation, but not pipeline updates. This is audit-log-worthy - which repo and what revision a pipeline runs controls what code a Nextflow user runs when they use a pre-defined pipeline, so changes to that are of interest for security reasons.

Although the Open API docs exist, there are no details on the fields themselves (e.g. when to use it, why to use it, what are its limitations etc) that could provide information about the nf-tower maps and their field limits and size.