Ever wish you could automatically remove your unwanted output files from a submission without having to manually review them? If so, take this two minute survey and tell us more.
Latest Release: 1/17/19
Release Notes can be found here.

Are config namespaces helpful/necessary within workspaces?

mnoblemnoble Broad Institute of MIT & HarvardMember, Broadie

Hi Team,

Over the last couple of days I've had the recurring thought that it's over-engineering to require config namespaces in workspaces. I can understand how for the Method repository such scoping is helpful, to organize methods and potentially distinguish those with the same name (because the method repo is global across FireCloud).

But I'm hard pressed to see the value-add in requiring such scoping within a workspace, nor do I believe it outweighs the complexity added to the UI and API. For one, it's very tough to imagine a use case where you'd need to have multiple methods with the same exact name, but which do different things, in a single workspace. Doesn't that smell more like bad design, rather than something we should foster? Second, but even if one's heart is set on constructing a workspace that way, it's cleaner and simpler to just name the configs differently (in the workspace) instead of also introducing another layer of scoping into the workspace. Third, requiring namespaces to be specified for method configs clutters many endpoints in the API with an extra parameter, such as

https://api.firecloud.org/#!/Method_Configurations/updateWorkspaceMethodConfig
https://api.firecloud.org/#!/Method_Configurations/getWorkspaceMethodConfig
https://api.firecloud.org/#!/Method_Configurations/validate_method_configuration

et al. And these would in general need to be exposed in the Python and CLI bindings, too (e.g. in https://github.com/broadinstitute/fiss)

Issue · Github
by Geraldine_VdAuwera

Issue Number
1726
State
closed
Last Updated
Assignee
Array
Milestone
Array
Closed By
vdauwera

Comments

Sign In or Register to comment.