Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve Visibility of Aggregator Private Attributes in Experimental Workflow #1084

Conversation

refai06
Copy link
Contributor

@refai06 refai06 commented Oct 8, 2024

Background

This PR solves the (Experimental Workflow Interface) Aggregator private attributes visible to Collaborators #1052

Change Description

  1. Created clones of the FLSpec object before starting flow execution in Aggregator to ensure that FLSpec object does not contain private attribues
  2. Removed the clone creation functionality from the next method of the FLSpec class
  3. Updated Aggregator do_task method to handle the filter_exclude_include functionality during the aggregator to collaborator transition.
  4. Removed the filter_exclude_include functionality from the next method of the FLSpec class

Modifications

openfl/experimental/component/aggregator/aggregator.py
openfl/experimental/interface/fl_spec.py
tests/github/experimental/workspace/testcase_private_attributes/src/aggregator_private_attrs.py
tests/github/experimental/workspace/testcase_private_attributes/src/testflow_privateattributes.py
tests/github/experimental/workspace/testcase_private_attributes_initialization_with_both_options/src/aggregator_private_attrs.py
tests/github/experimental/workspace/testcase_private_attributes_initialization_with_both_options/src/testflow_privateattributes.py
tests/github/experimental/workspace/testcase_private_attributes_initialization_without_callable/src/aggregator_private_attrs.py
tests/github/experimental/workspace/testcase_private_attributes_initialization_without_callable/src/testflow_privateattributes.py

Verification

Verified all testcases from tests/github/experimental/workspace

-tests/github/experimental/workspace/testcase_datastore_cli

-tests/github/experimental/workspace/testcase_include_exclude

-tests/github/experimental/workspace/testcase_private_attributes

-tests/github/experimental/workspace/testcase_private_attributes_initialization_with_both_options

-tests/github/experimental/workspace/testcase_private_attributes_initialization_without_callable

-tests/github/experimental/workspace/testcase_internalloop

-tests/github/experimental/workspace/testcase_reference

-tests/github/experimental/workspace/testcase_reference_with_include_exclude

-tests/github/experimental/workspace/testcase_subset_of_collaborators

Tutorials

Openfl-workspace/experimental/

-101_torch_cnn_mnist

-301_torch_cnn_mnist_watermarking

Comment on lines +258 to +265
self.execute_task_args = (
self,
f,
parent_func,
FLSpec._clones,
agg_to_collab_ss,
kwargs,
)
Copy link
Collaborator

@teoparvanov teoparvanov Oct 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove the private attribute filtering from here, then who is responsible for doing it, especially if we execute the FLSpec via the run() method, rather than through the export feature?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Private attribute filtering is required while transitioning from aggregator to collab (and vice-versa). For LocalRuntime it is done inside Participants (openfl/experimental/interface/participants.py) and in FederatedRuntime it is done inside Component (openfl/experimental/component/aggregator/aggregator.py and openfl/experimental/component/collaborator/collaborator.py)

Copy link
Collaborator

@teoparvanov teoparvanov Oct 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks for the explanation, @refai06 - the distinction is indeed not obvious for the "uninitiated" reader...

As a follow-up PR, I'd suggest re-organizing a little bit the code, to make it easier to navigate and review. Right now, everything related to Workflow API resides directly under openfl/experimental - thus implicitly "disallowing" other experimental features. Instead, it may be better to have a dedicated openfl/experimental/workflow package for example. Additionally, under openfl/experimental/workflow, we could imagine separate sub-packages for local, federated and export for example.

WDYT?

Copy link
Collaborator

@teoparvanov teoparvanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A general question regarding test coverage - do the test cases under tests/github/experimental/workspace cover both "runtimes":

  • the local runtime Aggregator and Collaborator classes in participants.py
  • the federated runtime Aggregator and Collaborator classes from experimental.component

?

@refai06
Copy link
Contributor Author

refai06 commented Oct 25, 2024

@teoparvanov :
The test cases under tests/github/experimental/workspace cover only Aggregator Based Workflow. For test cases related to the LocalRuntime, please refer to the testcase in openfl/tests/github/experimental

@teoparvanov teoparvanov merged commit 7aca44e into securefederatedai:develop Nov 4, 2024
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants