You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @bartvanb, following up on the conversation from several days ago about centralized aggregator where you asked me to create this issue.
By reading the code here, it looked like it would be impossible for a user to run the master algorithm on a node that is not their organization's node. But on further inspection it seems like that 'master' attribute is never sent on the POST at that level. It is sent I believe, but inside the serialized organizations.input, which might or might not be encrypted. So, I guess at the moment the server can't control on which node the master algorithm is allowed to run.
Perhaps it would be nice if node administrators had granular control over which part of an algorithm is allowed to run on their nodes (master, partial or both). But at the moment I don't believe this feature exists, and as you said, the expected behavior now is that users should be able to arbitrarily choose where the master runs (IIRC). So, maybe it's best if we remove this check for 'master' on the server? Provided I haven't missed anything, which is not unlikely :)
The text was updated successfully, but these errors were encountered:
Indeed it is common to define master=True/False within the input (see e.g. here). So I think your assessment is correct: the first code fragment which you refer to has no function and should be removed. I'll create a PR for that.
Regarding your point that it would be nice for node admins to control which algorithm parts may run on their node: agree! We aim to tackle that in the collaboration 'policies', but you may already create an issue for this specifically so that we keep it in mind
The node-admin control over which part of the algorithms is allowed to run was more of an afterthought to this issue, but sounds good, will create an issue to keep it in mind. In the meantime, is there already some code/documentation for the new 'collaboration policies' that I could check out?
No, there is not really any work done on the collaboration policies. At present, it is just an idea that we want to implement in the future, but there is no plan yet of how to achieve it exactly.
Hi @bartvanb, following up on the conversation from several days ago about centralized aggregator where you asked me to create this issue.
By reading the code here, it looked like it would be impossible for a user to run the master algorithm on a node that is not their organization's node. But on further inspection it seems like that 'master' attribute is never sent on the POST at that level. It is sent I believe, but inside the serialized
organizations.input
, which might or might not be encrypted. So, I guess at the moment the server can't control on which node the master algorithm is allowed to run.Perhaps it would be nice if node administrators had granular control over which part of an algorithm is allowed to run on their nodes (master, partial or both). But at the moment I don't believe this feature exists, and as you said, the expected behavior now is that users should be able to arbitrarily choose where the master runs (IIRC). So, maybe it's best if we remove this check for 'master' on the server? Provided I haven't missed anything, which is not unlikely :)
The text was updated successfully, but these errors were encountered: