Enhanced resource sharing in platform
acknowledged
B
Brass Wildcat
The existing sharing mechanism in Seqera Platform allows users to share pipelines across an organization. However, this mechanism:
- Exclusively supports the sharing of pipelines but does not yet extend to datasets, actions, or compute environments.
- It follows an all-or-nothing approach, granting access to shared pipelines to all workspaces, even when such access may not be required.
A more flexible sharing model might allow users to share:
- Compute environments
- Pipelines
- Datasets/data sources
Additionally, users could have the flexibility to define the sharing in a more granular way. For instance, they can specify which workspaces should have access to the shared resources, providing greater control over resource distribution.
This enhancement would aim to make resource sharing in Seqera Platform more versatile and user-centric, allowing for a more tailored approach to collaboration and resource accessibility.
Rob Newman
Merged in a post:
support for modules repos
C
Charcoal Mandrill
nf-core has a well known modules repository and system in place for using a centralized Nextflow modules repository in combination with the nf-core toolset to manage pipeline modules;
as the number of pipelines one's organization has to manage increases, the ability to utilize a central modules repository seems like a growing requirement. There is a blurb in the nf-core docs about usage of private internal modules repos;
Having a private internal remote modules repo would be a really great feature, and is arguably needed already by many users. However its not clear what kind of support for this is offered by Seqera and Seqera Platform (Nextflow Tower).
Can we get this as an official, first-party supported feature somehow?
Rob Newman
Merged in a post:
The ability to set workspace-level environment variables
Rob Syme
It is currently possible to set CE-level environment variables. If a workspace has multiple CEs, the variable needs to be set in each CE individually. There is also no way of changing the variable value after CE creation.
A workspace-level environment variable might allow the possibility of managing a single common variable inherited by all CEs in that workspace, reducing administrative work and ensuring that all CEs have the same value for the variable.
Rob Newman
Rob Syme: Moved your fine-grained sharing controls into this parent feature request. Thanks for your contribution!
Rob Newman
Merged in a post:
Choose which workspaces shared pipelines should be shared into
Rob Syme
Currently, all workflows in a shared workspace are shared with the entire organization. It would be helpful to provide more fine-grained sharing controls that allow both
1) a central way to modify/adjust pipelines across multiple workspaces
2) specific sharing options that provide access in a subset of the organisation's workspaces
Rob Newman
Yinmn blue Partridge: Thanks for your feature request! I'm merging it into the "Enhanced resource sharing" feature request which will be looked at in H2 2025. Appreciate your feedback as always.
Rob Newman
Merged in a post:
Create compute environments at the organization level
Y
Yinmn blue Partridge
It would be useful to have compute environments at the organisational level so they can be shared across workspaces without having to duplicate them.
This is similar to having a project view within a workspace but works the other way, moving the resources within the workspace up one level.
C
Charcoal Mandrill
are there any updates on this?
I feel like this is such an important topic that it warrants a blog post from Seqera on how to manage shared resources on Platform across Workspaces. Both in the current state, and details of the expected future changes to resource sharing. If such a blog post does not already exist, it would be greatly appreciated :)
note that it seems you can already share a Compute Environment across workspaces by configuring it once via TowerForge in the first Workspace then entering it Manually in the rest?
would also love to have some references for
tw
cli commands to manage some of this as well.Rob Newman
Charcoal Mandrill: There are not currently any updates on this. We have been investigating various options, including the idea of
Projects
, but nothing has been finalized.C
Continuous Squid
From an admin perspective, we could imagine the definition of pipelines and compute environment at the organisation level, with the possibility to assign it to the workspaces. Another benefit would be to be able to see all the runs for a single environment accross all workspaces.
Rob Newman
Merged in a post:
Define Org Level Compute
M
Mango Wolverine
Setting up new workspaces requires redefining all compute resources, credentials, container registries that pertain to our organization. However, those credentials and resources are largely shared within our group, and we'd prefer defining these once at the organization level by our admins.
B
Brass Wildcat
Merged in a post:
Global Management of Users, Groups, and Compute Environments
T
Tangerine yellow Ladybug
Inside the Seqera Platform/Tower, we created multiple organizations and sub-workspaces for organization of our runs. When we did this, we had to create groups in every organization.
As far as Compute Environments (CEs), we had to create them for every single workspace. This gets very tedious and is error prone in missing users or updates to CEs.
Groups should also be able to be assigned by group membership inside of the ODIC token from Okta to ease onboarding of a new user on a team.
As you can see above, if a new user comes on board, I need to go in and add that user to each group in each organization.
Load More
→