Seqera Platform Feature Requests

Currently, when customizing and building a Studio with conda, Wave uses a hardcoded imageSuffix naming strategy, which creates nested repository paths ( e.g., community.wave.seqera.io/data-studios/jupyter/numpy_scipy_tqdm_pip_pruned:7dc3ba408fd1df3c ). Whereas with Nextflow, Wave uses the none strategy by default. This causes issues when: Lacking ECR permissions to create repositories (ecr:CreateRepository) Needing consistency with Nextflow workflows that use different naming strategies We should enable configuration of the container image naming strategy in Wave Studios to support different registry requirements and structure constraints. I think there's two options: Env variable (specified at CE level or elsewhere) WAVE_STUDIOS_NAMING_STRATEGY=tagPrefix Configmap option (for self-hosted) wave: studios: namingStrategy: tagPrefix # none, tagPrefix, or imageSuffix

Currently, Data Explorer does not support previewing BAM or BED files. An in-platform, interactive experience can be provided by embedding the IGV Web App ( igv.js ) in Data Explorer. This allows in-browser previewing many common bioinformatic file types .

A task may fail to start if the container pull timeout is exceeded, for example. If the user has a task retry policy configured, Nextflow will re-submit the task to the queue. The task table shows no exit status (correctly), but does not offer information to suggest that the task did not succeed or why. This information is available in the Nextflow logs, but those logs won't be available until the run completes. It would be helpful if Platform displayed diagnostic and debugging information about tasks that fail to start.

Customer needs to export ephemeral YAML configuration files (e.g., that contain runtime parameters not found in standard logs. They want these configs exported as JSON alongside pipeline logs to maintain reproducibility after a from-scratch upgrade.

Testing

In light of the recent announcement & development of a Seqera Platform Terraform Provider ( https://feedback.seqera.io/feature-requests/p/cli-tool-needs-an-export-all-import-all-function-or-a-terraform-like-state-manag ; https://github.com/seqeralabs/terraform-provider-seqera ) I thought this might be a good opportunity to extend the concept one step further and consider build a full scale Seqera Platform SDK. Similar to the one for AWS here https://github.com/aws/aws-sdk-go-v2 Since the underlying Terraform provider methods are essentially just hitting the API endpoints for Platform, and the provider is already written in Go by necessity for Terraform, it seems like it could be possible and appropriate to have the API client interface for Seqera Platform useable as an independent stand-alone Go library which could both be used by the Terraform provider, and imported for use in other custom programs. This would be a very nice compliment to seqerakit https://github.com/seqeralabs/seqerakit and would expand the ways in which users could programmatically interface with Seqera Platform, and integrate Seqera Platform deeper into the rest of their custom internal infra stacks.

Seqera supports running workflows across many different types of compute infrastructure. Pipelines in some cases may have unutilised compute, which increases costs. The start up time, especially on some types of batch compute, may significantly increase. Scheduler is a multi-phased project designed to simplify compute configuration options and reduce the time and cost of running a pipeline by intelligently choosing the right configuration for a workflow and scaling the infrastructure at the correct tasks within the pipeline to remove overprovisioning or resource contention issues

When deploying Seqera Enterprise in kubernetes, the images come from cr.seqera.io . Currently, if deploying to AWS EKS, it would be great to create a pull through cache for the Seqera Platform images. This avoids making Kubernetes pull directly from Seqera's proprietary container registry every time a pod is launched. It also avoids pulling over the public internet. You can setup an ECR repository as a pull through cache. This allows customers to setup their credentials in the AWS account once (via AWS Secrets Manager) and now all images will be cached in the local ECR repository. AWS ECR only support pull through cache: From the docs ( https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html ): Amazon ECR currently supports creating pull through cache rules for the following upstream registries: Amazon ECR Public, Kubernetes container image registry, and Quay (doesn't require authentication) Docker Hub, Microsoft Azure Container Registry, GitHub Container Registry, and GitLab Container Registry (requires authentication with AWS Secrets Manager secret) Amazon ECR (requires authentication with AWS IAM role) It would be great if Seqera could also use a recognized container registry to host their images to allow common registry integrations.

It would be great if you could package your installation up into a helm chart, where we could simply set the necessary variables all in one place. This would simplify the container installation on EKS and have this much more repeatable in terms of installation. We have multiple environments to install this application in, and we've spun up EKS with Terraform. However, the installation of Seqera Platform is quite hands-on and manual. It would be a benefit to have a helm chart with the necessary configuration options available. Thanks MarkA

I'd like to be able to chain pipelines together within Seqera Platform, and not rely on an external service such as lambda functions to chain demultiplex => rnaseq => differentialabundance together for example