Overseer agent sp_end_point allow for HTTP2 gRPC routing

[dean-taylor]

../startup/fed_server.json
overseer_agent.args.sp_end_point="server:8002:8003"

GRPC is a HTTP2 protocol which requires a layer 7 application service to intelegently direct packet flow to backend service.

At present external access to NVFlare service can only be managed at layer 4 with either direct access to the service host via external IP address allocation or a very simple load balancer configuration.

This rules out common security patterns involving routing gRPC traffic via supporting ingress controllers and more importantly the involvement of higher security services such as service mesh implementations like Istio and others.

Describe the solution you'd like
An alteration to the code that supports the "sp_end_point" setting:

1. allow a variation that provides:

• an independent service URL for each of the fl and admin port settings, something like "sp_end_point": "fl-server:443:admin-server:443". This allows an ingress controller such as ingress-nginx to map DNS names of the same standard external port "443" or "80" to the NVFlare server backend. and/or
• "server/fl:server/admin:443" allowing 'virtual hosts' paths on the same URL to target backend NVFlare service.

2. keep the current format of single server URL to fl and admin port mappings for backward compatibility.
3. Merge the fl and admin ports into a single gRPC service involving a single port assignment (I have not looked at this within the code to assess viability so may be completely off base).

Describe alternatives you've considered
ATM only directly exposing host ports or basic load balancer configuration are viable.

Additional context
We currently utilise Kubernetes with Ingress controllers as a base line service provider and for high security contexts such as some proposed FL deployments additions such as a Service Mesh are invaluable. This requires certain HTTP2 functionality to appropriately route, secure and monitor gRPC traffic with is difficult and in some cases such as standard ingress controllers (many of which a team will not be able to modify as per the ingress-nginx instructions) not possible in its current form.

[yanchengnv]

Connectivity is a complex issue, and there are many ways to do it. NVFlare 2.6 provides a feature called "Bring Your Connectivity" that will allow you to use any connectivity solutions, as long as such solutions ensure that the client can communicate with the server. Basically, you can provision the server and each client to listen/connect to any addresses, but you make sure that your arrangement of these addresses provide communication path between client and the server.

[chesterxgchen]

you brought interesting suggestions, we will take a look