Seqera Platform Feature Requests

It's quite common to point a Nextflow process at a different compute environment than the one the platform submits to. E.g when we create a second compute environment called "myGpuComputeEnvironment", we can point a process at it with a config file like so: process { withLabel: "GPU" { queue = "TowerForge-3d21D1WBJ80hWpvZ9x7ks1" } } But you have to rummage around in the AWS/Azure/GCP console and find that unique ID which can be frustrating. Instead, it would be much better if we could use the compute environment names from Seqera Platform, like so: process { withLabel: "GPU" { queue = "myGpuComputeEnvironment" } } The platform performs a switch under the hood to point myGpuComputeEnvironment to TowerForge-3d21D1WBJ80hWpvZ9x7ks1 , but the user has a much easier interface for re-directing a process to a different queue. In addition, if I delete and re-make myGpuComputeEnvironment it will automatically re-point to the right compute environment. This would enable more complex deployments of compute environments while still using the same interface.

Currently, the Execution Logs tab in the View Workflow Run does not update automatically if the compute environment is not one of AWS Batch, GCP or Azure. A user would expect that the logs appeared in this window as they are emitted by the back-end. Instead, it is necessary to refresh the page or change tabs to see the latest information. It would be a nice improvement to be able to see the logs in real time. It would be a nice improvement to be able to see the logs in real time for other compute environments (e.g., SLURM).

Support the configuration of virtual network / subnets for Azure compute environments in Seqera platform. It will use the azure.batch.pools.<name> spec, that is currently supported by nextflow

I want to be able to configure the machine types to use when creating a Compute Environment using Google Batch. Currently, in order to specify machine types, I need to do this through Nextflow configuration for each individual run with process.machineType. = "n1-*" . Similar to other provides like AWS and Azure, I should be able to specify machine types or families to use in the CE form under a field titled "Instance Types" or similar.

Similar to how there are already metrics for non-GPU environments that enable users to see their utilization and make optimization decisions, add support for GPU environments as well.

It seems the value of process.scratch is set to true by default for cloud-based executors such as AWS Batch . We are experimenting with using FSx for Lustre to provide scratch space for certain workflows, but we don't seem to be able to create a Compute Environment in which writing to the FSx for Lustre mount (within the workDir ) is the default. Is there a way to do this? I understand that for every run, we could override process.scratch = false in nextflow.config , but it would be far preferable to set this in the Compute Environment since it is the Compute Environment configuration in which we decide to provide FSx for Lustre as scratch space instead of selecting nodes with substantial/fast local scratch space.

Currently TowerForge creates 3 roles (in AWS): InstanceRole ExecutionRole ServiceRole It is possible to override the ExecutionRole by setting the "Batch execution role" in the TowerForge GUI. It is not possible to override the InstanceRole or ServiceRole , however. It would be useful for us to be able to override the InstanceRole (in our case to limit the KMS permissions provided in the default InstanceRole ), and provide a custom one to use instead of TowerForge creating one.

On the Seqera Add Credentials page, both Access and Secret keys are mandatory fields, even when specifying a role. We're interested in exploring the possibility of exclusively utilizing role-based access without the need to provide credentials.

We use a Lustre drive to store a set of reference files and datasets. We're trying to mount the drive from a different AWS account than the one it was created in. We can do so on EC2 instances just fine, but Tower Forge will only show us Lustre drives from the local AWS account, presumably because it's getting the full mount info automatically on the back end. If you provide an option to manually enter the mount info (for instance, <lustre ip>@tcp:<mount point> ), we can use the same lustre drive across multiple accounts.

At the moment if you want to fix a Nextflow version, you have to use a pre-run script to export the NXF_VER environment version. This is fine, but it's not intuitive for what is a fairly central part of the experience of running Nextflow on Seqera Platform. Suggestion is to have a new field in the UI to set the Nextflow version. This could potentially be when creating a new Compute Environment, ideally with a secondary field which could be set when launching a workflow (either to set new or to override the default in the CE). The field should default to using the latest stable release of Nextflow, but give the option of using the latest edge release instead, or a specified exact release version.