the latter issues a warning on startup that this is deprecated and will not be supported in the future:
warning: no-jdk distributions that do not bundle a JDK are deprecated and will be removed in a future release
what are the plans of opensearch here?
directly abandon the no-jdk distribution
keep the no-jdk distribution but flag it as deprecated and kick it out with a future major release
keep the no-jdk distribution fully supported
what is the update strategy for the bundled JDK? how fast will you update all still supported versions of opensearch with an updated JDK if one comes out (esp. if that contains security fixes)?
and which JDK do you plan to bundle, anyway? (with all the licensing implications, etc.)
having the no-jdk distribution has the advantage that we can roll our own docker image with our preferred base image (which is trusted, signed & security-reviewed and contains the latest JDK in the flavour we prefer). this allows us to have a very homogenous landscape in terms of JVMs running in our application stack (makes tracking bugs & security relevant things easier) and - typical big corporation - makes getting approvals from security & co. easier (i donāt have to onboard yet another JDK / JDK vendor).
Your reasoning seems pretty sound to me. Iād like to hear what others say but barring any major dissenters, it might be a basis for a more formal proposal.
Yeah, Iād love to hear preferences and ideas about how to mitigate the tradeoffs for a feature like this. Obviously, itās easy to set a different JAVA_HOME to replace/override the bundled JDK with one of your preference, even in the bundled-jdk distribution - but that still does involved downloading bytes you arenāt going to use.
For users of a no-JDK version, what would you expect as far as how thoroughly OpenSearch is tested/supported with JDKs other than the one itās normally shipped with? Would it be preferable to have the ability to choose among distributions that are built / shipped / tested with specific JDKs, if that made it easier for those JDKs to be supported?
if i saw it correctly then elasticsearch is bundling AdoptOpenJDK. what are the plans for opensearch? will you continue with this or will you e.g. move to Amazon Corretto (because opensearch is currently mainly driven by AWS, so you might have some interest in using your own products)?
iām actually fine with AdoptOpenJDK and think that it makes sense to test against this, since itās - according to wikipedia - an unmodified build from upstream (unlike most others). so if it works with that it should work with others.
then the question remains for how updates to the JDK will be handled. because, even if itās an āacceptedā JDK not having the updates under control is a bit of an issue.
downloading opensearch with a bundled JDK but then using your own JDK instead feels wrong:
you waste valuable storage space, esp. in docker images
security & license scanning tools will still always pick up the bundled JDK (these tools are not intelligent enough to understand that youāre not using it even though itās in your container)
if you instead delete the bundled JDK every time this is just an unnecessary additional step and makes things more complex than they need to be
Yeah @ralph, it makes total sense that if youāre planning to use a different JDK anyway, it would be great to have an ability to not even download the default one.
Any discussion of changing the default JDK would happen here and/or with an RFC. The long term support offered with Amazon Corretto is appealing, as it would provide a straightforward answer to your question about how to handle JDK updates: the upstream vendor would have a stated support commitment. But there are a ton of variables to consider.
My question around the āno-bundled-jdkā option is, would you as a user expect āno JDKā to effectively mean āall JDKsā - i.e. that releases are tested and supported equally well for any JDK you choose to use? That could get complex. Or would there be a different expectation? How do you think about this?
this just answers the part of the JDK vendor. it does not answer how fast opensearch will be able to publish an update to the distribution.
weāre currently also using AdoptOpenJDK, so the main reason for me to use the no-jdk distribution would be that i can use our āstandardā in-house java base image which is kept up-to-date and is guaranteed to be set up in a way our infrastructure & security people are happy with and we have an easy way to track if we need to update something. if it comes as a black box with opensearch we might not notice if itās outdated (or rather: weāll notice it, but via our scanning tools and worst case weāll have to wait for a new opensearch release to update the JDK).
as stated before i think that if you test against an unmodified JDK (e.g. AdoptOpenJDK) then it should be fine. anyone using a modified JDK has to ensure compatibility on their own.
i just noticed that the āminimalā distribution (Opensearch 1.0.0 Min Linux X64 Ā· OpenSearch) still ships with a JDK.
is this intentional? i was really hoping that the minimal distribution would be without a JDK.
or could we get a āminimal-no-jdkā (and maybe also a ānormalā āno-jdkā) distribution?
should i raise a ticket (didnāt find an open one for this) for this or are there specific reasons why you absolutely wouldnāt want to do this?
Definitely please open an issue in the build repo. That would be a big help!
Weāre working to add more distribution options that users are asking for as fast as we can. Thereās a list, and letās just get this onto the list. Weāre also working in parallel on an open build infrastructure that would let anybody contribute toward a new distribution type they care about, and more testing automation so that itās easy to thoroughly test all these distributions.