Defining use-case regisitries at the central node #264
Description
I was trying to setup a Brane central node and communicate with it the other day, and I've stumbled across something unexpected: the scientist has to give a use-case when submitting a workflow to a Brane instance. Maybe it's intended - but then I posit that this shouldn't have to be the case. Or, since I know it's all quite confusing with these use-cases, maybe it's just a misunderstanding so let me try to explain why I think it shouldn't be the case :)
The idea is that use-cases kind of match up with instances (at least, for now), meaning that a Brane central node defines a use-case. The use-case string is, then, only used by central nodes to tell workers which central node is contacting them: you can almost think of it as a business card, simply allowing the worker to connect to the right brane-api-service. This used to be done by passing an actual address, but, somehow, asking workers to connect to arbitrary domains before any policy is involved was not approved of by hospital security sites. How weird.
The scientist/user, by contrast, already knows which use-case they are referring to when sending their workflow to the central instance in question. As such, is surprises me that they have to pass it.
I can imagine that maybe there's some information-reason that it's there? I.e., the scientist needs to supply it in a workflow or something? If so, then, if possible, it'd be great if the central node can inject it instead. Or, alternatively, that the user can request the concrete identifier from the instance it's connected to or something. As these are infrequent / never change, it should suffice to do this once when adding a new instance to the brane instance keychain, for example.
That said, the use-case of the current central node is hardcoded to central. Maybe this should be added to the node.yml file as an option, much like the location_id is over at the workers :)