Skip to content

Flower 1.11.0

Latest
Compare
Choose a tag to compare
@github-actions github-actions released this 30 Aug 12:43
· 27 commits to main since this release
0f7bbe1

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Edoardo Gabrielli, Heng Pan, Javier, Meng Yan, Michal Danilowski, Mohammad Naseri, Robert Steiner, Steve Laskaridis, Taner Topal, Yan Gao

What's new?

  • Deliver Flower App Bundle (FAB) to SuperLink and SuperNodes (#4006, #3945, #3999, #4027, #3851, #3946, #4003, #4029, #3942, #3957, #4020, #4044, #3852, #4019, #4031, #4036, #4049, #4017, #3943, #3944, #4011, #3619)

    Dynamic code updates are here! flwr run can now ship and install the latest version of your ServerApp and ClientApp to an already-running federation (SuperLink and SuperNodes).

    How does it work? flwr run bundles your Flower app into a single FAB (Flower App Bundle) file. It then ships this FAB file, via the SuperExec, to both the SuperLink and those SuperNodes that need it. This allows you to keep SuperExec, SuperLink and SuperNodes running as permanent infrastructure, and then ship code updates (including completely new projects!) dynamically.

    flwr run is all you need.

  • Introduce isolated ClientApp execution (#3970, #3976, #4002, #4001, #4034, #4037, #3977, #4042, #3978, #4039, #4033, #3971, #4035, #3973, #4032)

    The SuperNode can now run your ClientApp in a fully isolated way. In an enterprise deployment, this allows you to set strict limits on what the ClientApp can and cannot do.

    flower-supernode supports three --isolation modes:

    • Unset: The SuperNode runs the ClientApp in the same process (as in previous versions of Flower). This is the default mode.
    • --isolation=subprocess: The SuperNode starts a subprocess to run the ClientApp.
    • --isolation=process: The SuperNode expects an externally-managed process to run the ClientApp. This external process is not managed by the SuperNode, so it has to be started beforehand and terminated manually. The common way to use this isolation mode is via the new flwr/clientapp Docker image.
  • Improve Docker support for enterprise deployments (#4050, #4090, #3784, #3998, #4094, #3722)

    Flower 1.11 ships many Docker improvements that are especially useful for enterprise deployments:

    • flwr/supernode comes with a new Alpine Docker image.
    • flwr/clientapp is a new image to be used with the --isolation=process option. In this mode, SuperNode and ClientApp run in two different Docker containers. flwr/supernode (preferably the Alpine version) runs the long-running SuperNode with --isolation=process. flwr/clientapp runs the ClientApp. This is the recommended way to deploy Flower in enterprise settings.
    • New all-in-one Docker Compose enables you to easily start a full Flower Deployment Engine on a single machine.
    • Completely new Docker documentation: https://flower.ai/docs/framework/docker/index.html
  • Improve SuperNode authentication (#4043, #4047, #4074)

    SuperNode auth has been improved in several ways, including improved logging, improved testing, and improved error handling.

  • Update flwr new templates (#3933, #3894, #3930, #3931, #3997, #3979, #3965, #4013, #4064)

    All flwr new templates have been updated to show the latest recommended use of Flower APIs.

  • Improve Simulation Engine (#4095, #3913, #4059, #3954, #4071, #3985, #3988)

    The Flower Simulation Engine comes with several updates, including improved run config support, verbose logging, simulation backend configuration via flwr run, and more.

  • Improve RecordSet (#4052, #3218, #4016)

    RecordSet is the core object to exchange model parameters, configuration values and metrics between ClientApp and ServerApp. This release ships several smaller improvements to RecordSet and related *Record types.

  • Update documentation (#3972, #3925, #4061, #3984, #3917, #3900, #4066, #3765, #4021, #3906, #4063, #4076, #3920, #3916)

    Many parts of the documentation, including the main tutorial, have been migrated to show new Flower APIs and other new Flower features like the improved Docker support.

  • Migrate code example to use new Flower APIs (#3758, #3701, #3919, #3918, #3934, #3893, #3833, #3922, #3846, #3777, #3874, #3873, #3935, #3754, #3980, #4089, #4046, #3314, #3316, #3295, #3313)

    Many code examples have been migrated to use new Flower APIs.

  • Update Flower framework, framework internals and quality infrastructure (#4018, #4053, #4098, #4067, #4105, #4048, #4107, #4069, #3915, #4101, #4108, #3914, #4068, #4041, #4040, #3986, #4026, #3961, #3975, #3983, #4091, #3982, #4079, #4073, #4060, #4106, #4080, #3974, #3996, #3991, #3981, #4093, #4100, #3939, #3955, #3940, #4038)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Deprecations

  • Deprecate accessing Context via Client.context (#3797)

    Now that both client_fn and server_fn receive a Context object, accessing Context via Client.context is deprecated. Client.context will be removed in a future release. If you need to access Context in your Client implementation, pass it manually when creating the Client instance in client_fn:

    def client_fn(context: Context) -> Client:
        return FlowerClient(context).to_client()

Incompatible changes

  • Update CLIs to accept an app directory instead of ClientApp and ServerApp (#3952, #4077, #3850)

    The CLI commands flower-supernode and flower-server-app now accept an app directory as argument (instead of references to a ClientApp or ServerApp). An app directory is any directory containing a pyproject.toml file (with the appropriate Flower config fields set). The easiest way to generate a compatible project structure is to use flwr new.

  • Disable flower-client-app CLI command (#4022)

    flower-client-app has been disabled. Use flower-supernode instead.

  • Use spaces instead of commas for separating config args (#4000)

    When passing configs (run config, node config) to Flower, you now need to separate key-value pairs using spaces instead of commas. For example:

    flwr run . --run-config "learning-rate=0.01 num_rounds=10"  # Works

    Previously, you could pass configs using commas, like this:

    flwr run . --run-config "learning-rate=0.01,num_rounds=10"  # Doesn't work
  • Remove flwr example CLI command (#4084)

    The experimental flwr example CLI command has been removed. Use flwr new to generate a project and then run it using flwr run.