[Extensibility] Too(?)-tightly coupled

[DazWilkin]

Is your feature request related to a problem? Please describe.

Extensibility is tightly-coupled.

Protocol changes require agent, controller and CRD rebuilds and redeployments.

It seems that this system would benefit from being dynamic though I can't provide guidance on how to achieve this beyond it being a good use-case for gRPC.

[kate-goldenring]

Definitely agree. We would love to have discovery protocol handlers to be modularized such that they do not require changes to Akri's core components. We've created a proposal for this here.

[DazWilkin]

Outstanding!

FWIW options 3 and 4 seem to be the most compelling

[DazWilkin]

A benefit of option 3 is that you don't prescribe the language used to implement the discovery agent beyond the broad list of languages that have gRPC SDKs.

[DazWilkin]

As I explore extending the Agent to support ZeroConf, it (actually the Rust zeronconf crate specifically) requires additional shared libraries. Such additions:

1. Require revising the Dockerfiles to include the additional packages;
2. Increase the possible attack surface of the images;
3. Increase the size of the images;
4. Possibly contaminate other protocols (dependency mismatch etc.)
5. May require enterprise security re-ups on auditing, licensing etc.

Example:

zeroconf (0.6.2) requires: xorg-dev, libxcb-shape0-dev, libxcb-xfixes0-dev, clang

[DazWilkin]

... and, shared library additions require providing|testing equivalent changes for each platform