docs(framework) Add how-to run flwr with deployment engine guide

[Robert-Steiner]

Issue

Description

Related issues/PRs

Proposal

Explanation

Checklist

• Implement proposed change
• Write tests
• Update documentation
• Make CI checks pass
• Ping maintainers on Slack (channel #contributions)

Any other comments?

[jafermarq]

Hey @Robert-Steiner , i like the flow. Some comments below. I'm thinking to merge this as soon as we release 1.13.0 which will have fused SuperLink and SuperExec.

[jafermarq]

I'm thinking we can remove this step?

[jafermarq]

Suggested change

	* | ``--node-config "partition-id=0 num-partitions=2"``: Set the partition ID to ``0`` and the
	| number of partitions to ``2`` for the SuperNode configuration.
	* | ``--node-config "partition-id=0 num-partitions=2"``: Set the partition ID to ``0`` and the
	| number of partitions to ``2`` for the SuperNode configuration. This is needed because the
	| PyTorch template used was designed with the Simulation Engine in mind. In a real-world setup using the Deployment Engine, you'd instead pass in :code:`--node-config` the path to your local dataset.

[jafermarq]

i thought of adding a bit more context. Just to explain that those partition-id and num-partitions keys are just there because the ClientApp in this particular template needs them. A normal distributed setup would likely use other keys... do you think there's a clearer way of saying this?

[Robert-Steiner]

That makes sense to me. We could also use the PyTorch Quickstart example to provide a more realistic use case. wdyt?

[jafermarq]

Suggested change

	--isolation subprocess
	--isolation subprocess
	.. dropdown:: Understand the command
	* ``--supernode-address 127.0.0.1:9094``: Note how we indicate a different port. This is because if you run two `SuperNodes` on the same machine, they can't make use of the same port to communicate with the sub-process executing the `ClientApp`.

[jafermarq]

another option would be to skip showing this second flower-supernode command and say: "if you run in a different machine, run exactly as before. If on the same machine, just change the port". This sounds like a better way to me but then the question is: should we present the --superlink IPs in a more general way instead of assuming them being localhost?

[Robert-Steiner]

What about using a tab component and show both versions (localhost, different host)?

[jafermarq]

Hey @Robert-Steiner , i like the flow. Some comments below. I'm thinking to merge this as soon as we release 1.13.0 which will have fused SuperLink and SuperExec.