Re: Non JSON-query API clients

[Gian Merlino]

I'm not aware of plans to build out official clients for those other APIs;
when I've written python programs to integrate with them I've usually
called them through http directly.

I'm not familiar with OpenAPI, but looking at it briefly, it seems like an
interesting concept and a potential way to get some nice clients going.

The API endpoints are stable, in the sense that they change rarely, and if
they ever do change it will be in a major version and will be called out in
the release notes.

On Fri, Nov 6, 2020 at 7:56 AM ayoub mrini  wrote:

> Hello,
>
> I'm aware of some Python clients for the JSON query API, but I cannot find
> any Python client for the other endpoints, the ones documented here:
> https://druid.apache.org/docs/latest/operations/api-reference.html
>
> Are planning to provide any official ones? Are those endpoints stable?
>
> If we can write the OpenAPI spec, for example, for those endpoints, we can
> generate the basic boilerplate client code for multiple langages.
>
>
> Ayoub Mrini
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org
> For additional commands, e-mail: dev-h...@druid.apache.org
>
>

Re: [E] Re: Removing Druid support for JDK 8 and adding support for JDK 11

[Gian Merlino]

Seconding (thirding?) the idea that keeping JDK 8 for integration with
Hadoop is important. Druid's Hadoop integration is built against Hadoop 2.x
and that version only supports JDK 8:
https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Java+Versions. We
shouldn't drop JDK 8 support until we move to Hadoop 3.3 or later (or drop
the Hadoop integration completely).

The costs of keeping things stable on JDK 8 don't seem that high. The ones
Suneet raised were:

1) Java 8 is end of life.
2) We can reduce our Travis usage by almost half.

As Xavier pointed out, though, (1) isn't wholly fair since there are still
plenty of supported enterprise distributions for JDK 8. And ASF Infra
hasn't complained to us about (2).

To me, the benefits of dropping JDK 8 support don't outweigh the downsides.

I do think we should start telling people to deploy on JDK 11 by default,
though, and we should focus any future expansion of testing efforts (like
perf tests, etc) on JDK 11. I would whole-heartedly support this for the
next Druid release.

I also agree with Julian that supporting newer JDKs, if feasible, would be
good too.

On Thu, Nov 12, 2020 at 5:25 PM Xavier Léauté  wrote:

> I agree with Himanshu we should keep JDK 8 support for integrations if we
> feel those are important.
>
> As far as lifecycle goes, JDK 8 support will continue as part of several
> linux distributions.
> For instance, RedHat has taken on the role of publishing clean upstream
> builds for OpenJDK JDK8
>  and JDK11
>  updates,
> with
> support until 2026 .
> This means JDK8 will probably not go away for some time with enterprise
> users.
>
> Before we can even deprecate 8 we should at least make 11 (or later) the
> default / preferred JDK version.
> What would help is to have some first hand accounts of people running
> production deployments with 11.
> I don't think we have a good sense of whether there are any significant
> performance differences between 8 and 11.
> We should rule out any regressions before we make it the default.
>
> I also agree with Julian that we should keep the ball rolling. The biggest
> hurdle was (hopefully) to get from 8 to 11,
> and the changes for 15 should hopefully be smaller, but it's important we
> keep the momentum going.
>
> Generally I would recommend we support the LTS JDK versions + the latest
> Other projects (e.g. Apache Kafka) does the same and builds 8+11+15.
> If we are concerned about build times, we can consider running integration
> tests for preferred version
> and reserve the full suite of JDKs for release candidates.
>
> Xavier
>