Adrian reminded me that this thread existed. I'll offer my 2 cents here, I think that the storage/reporter implementations that send to the vendor backends do not belong in the same repos as the Zipkin and Zipkin library extensions that enable Zipkin use within cloud environments. The distinction between this being that, the components that are usable within the Zipkin ecosystem, no matter the backend, and those that provide system interop with other ecosystems. IE: we treat StackDriver and XRay the same way we would NewRelic or Datadog or Haystack exporters if they existed.
With the current status of these repos, that would mean zipkin-gcp does not get moved to the ASF, and zipkin-aws would have the XRay components extracted out of it to a new repo, perhaps: zipkin-xray, and then it would be in a good place to be moved. - Brian On Wed, Feb 13, 2019 at 9:15 PM Adrian Cole <[email protected]> wrote: > Currently the biggest technical risk beyond api drift is Google's use of > gRPC over ssl. This is not a problem for Amazon. > > gRPC is a crazy sensitive dependency tree including BoringSSL native > drivers. This is very time consuming to debug. Some of this goes away JRE > 11+ but the "slim" images provided by openjdk are huge (350MiB where our > while image is less than 150) > > StackDriver adds to that oauth etc. but most support problems have been > around grpc unless memory is incorrect. > > On Thu, Feb 14, 2019, 10:08 AM Andriy Redko <[email protected] wrote: > > > Hey Adrian, > > > > I think this is a difficult choice to make, for any project which faces > > similar challenges. > > From one perspective, those repos (GCP and X-Ray integration) are > valuable > > contributions, > > the Google Cloud and AWS are very popular platforms so having Zipkin > > presence there is > > a huge plus. But maintenance wise, as per your concerns, neither Google, > > nor Amazon have > > interest in supporting it (building own solutions?). I think there are at > > least two > > questions to ask and, depending on the answers, make a decision: > > > > 1. Do we have contributors who could / are interested in maintaning the > > projects? > > 2. Any risks that at some point, Google or Amazon would make the > > integration difficult / impossible? > > > > We may ask Google or Amazon folks, as you suggested, if they could help > us > > out. If not, could we > > involve community members? If there is no interest, we probably are > better > > off not moving them. > > > > Thanks. > > > > Best Regards, > > Andriy Redko > > > > > > AC> Hi, folks. > > > > AC> SaaS providers such as Google, routinely change their apis and not > > AC> always is the support good when that occurs. Many have an agenda to > > AC> use their own native clients as well (regardless of naming prefix). > > AC> Controlled ecosystems, whether that's private apis or golden path to > > AC> 3rd party libraries can be tricky. While Amazon and Google currently > > AC> don't actively try to stop Zipkin ecosystem, we hardly ever get any > > AC> support from either. Notably, the GCP repository has had numerous > > AC> complaints and while Google originally helped write it, they no > longer > > AC> help. > > > > AC> All this in mind.. should we move repos like this into the ASF? > > AC> Notably, the google one is more troubling support wise, but also the > > AC> Amazon X-Ray component of the aws project has been incomplete for > > AC> years. OTOH, notably in zipkin-aws, there are many stable used > things, > > AC> like SQS transport. > > > > AC> I think the tension is around lack of support around cloud tracing > > AC> backends and this causes a bad user experience. > > > > AC> What do you think? If we did move the SaaS backends into Apache, what > > AC> could we ask google or amazon for to ensure their health? When would > > AC> we delete these backends if they drifted and ceased to help? > > > > AC> For consideration, the last wiki I wrote on this topic is here > > AC> https://github.com/Netflix/denominator/wiki/Adding-new-Providers > > AC> -A > > > > AC> --------------------------------------------------------------------- > > AC> To unsubscribe, e-mail: [email protected] > > AC> For additional commands, e-mail: [email protected] > > > > > > >
