Mike, I think what you're saying is you are debating two options: A) gRPC as a transport mechanism and support the deployment use cases from the HTTP s2s document [1] to include using nifi-specific peer selection in the client if the destination is a cluster. B) Building a different implementation with an additional deployment case, which is sending from a client (in the diagrams as NiFi site-to-site client) to a cluster which isn't NiFi and delegating peer selection "to gRPC" which lightens what the receiving cluster would have to implement?
Sound pretty close to the decision you're looking for input on? 1. https://cwiki.apache.org/confluence/display/NIFI/Support+HTTP%28S%29+as+a+transport+mechanism+for+Site-to-Site#SupportHTTP(S)asatransportmechanismforSite-to-Site-Deploymentexamples On Tue, Jun 6, 2017 at 2:28 PM, Michael Hogue <[email protected]> wrote: > All, > > As an initial dive into nifi i elected to take a stab at NIFI-3641 > <https://issues.apache.org/jira/browse/NIFI-3641> (in particular, the > site-to-site bit), but i've got a few high level questions before taking > off down a path. > > Would it be more desirable to have a gRPC site-to-site mechanism or the > ability to generally interact with external gRPC services, such as tensor > flow, in a processor? That might help guide the approach I take in > addressing the issue. I'm not entirely sure it's possible to do both with > the same solution since the current site-to-site API assumes the other end > is a nifi. On top of that, gRPC provides a number of load balancing, remote > gRPC server (i.e. peer) selection, and serialization mechanisms that the > current site-to-site implementation does itself. > > What i'm looking for here are some thoughts and/or guidance on a > recommended approach and intended goal. > > Thanks, > Mike >
