subbu has quit [Remote host closed the connection]
subbu has joined #jruby
subbu has quit [Quit: Leaving]
daveg_lookout[m] has quit [Quit: You have been kicked for being idle]
<headius>
Good morning!
<nilsding>
good evening :)
<headius>
😃
subbu has joined #jruby
<headius>
enebo: I'm having a call later with George from Oracle about this docker image thing
<headius>
I have not switched us away from the open JDK images but I'll report back when I hear more about the support situation
<enebo[m]>
headius: ah ok cool
kroth_lookout[m] has quit [Quit: You have been kicked for being idle]
subbu has quit [Ping timeout: 246 seconds]
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<headius>
enebo: ok so here's the deal
<headius>
Oracle publishes free binaries of OpenJDK, but they only do so along the 6-month release cadence. That means release plus two updates, and then when the next release comes out they start basing the binaries on that version
<headius>
So based on that, that is why we see no updates of 17 now that 18 is out, and this is what the Docker Hub images are based off of
<headius>
so the Docker folks raised the issue because anyone thinking the "openjdk" namespace on hub is always an official latest build of that version might not realize those stop getting updates
<headius>
meanwhile, anyone deploying to production probably should not be depending on those images, and should instead pick oraclejdk or temurin or corretto or whatever
<headius>
so I'm thinking the path forward for us would be something like this
<headius>
1. As long as the openjdk images are being updated with latest release of latest version, we will push a jruby image based on those "tip" builds
<headius>
these images will always track latest openjdk, so we would only have a jruby-openjdk images on 18.whatever right now
<headius>
2. We will work with users to see what other **official and supported** baseline JDK they want, and why they want us to build images based on those JDKs
<headius>
I don't want to permute every commercially-supported JDK image in our releases, but if there's a compelling reason for us to push a JRuby on latest Temurin 17, we can still do that
<headius>
I'm open to other suggestions, but I think I get the situation now... the OpenJDK project does source releases only, there are no official builds because there's no support organization behind "openjdk"
<headius>
so you have to choose someone's build
<enebo[m]>
Having heard all this I don't see why we don't just use Temurin for all of it
<enebo[m]>
Do they also not publish security updates in older JVM images?
<headius>
Georges likened it to Linux, in that there's no official builds of any Linux kernels, but there's builds provided and supported by various distributions
<headius>
I'm not sure how far back this policy goes
<headius>
17 images are definitely behind, on 17.0.2 now versus the actual 17.0.3.1.1 that is official
<enebo[m]>
17 images of openjdk published by Oracle as part of openjdk
<headius>
switching all of the "jruby" image to Temurin would seem fine to me if that's the one we want to bless, but what is our justification for Temurin over any other?
<headius>
Because we are at IBM?
<headius>
I don't have a good answer
<headius>
17 images pushed for free by Oracle are done as of 18
<enebo[m]>
Well I think what we pick can be a set of filters
<headius>
once 19 comes out they will stop pushing 18 builds and images
<enebo[m]>
the first filter is which ones does builds of older JVMs for security builds and won't have people opening issues wondering why we are behind
<headius>
so this is the lead in to "if you want updates of 17 past the release of 18 you need to pick a vendor"
<enebo[m]>
If we pick someone who does not do this then we do not have to explain this until someone says why didn't you use openjdk
<headius>
we can also push a jruby-openjdk that is always on the latest openjdk image, on the same six-month cadence as the oracle biulds they are based on
<enebo[m]>
I know how an image is made and blessed is a detail which may be important to some but not having latest point with CVEs addressed seems more relevant right?
<enebo[m]>
but one thing I don't think we can afford to do is keep pushing more and more things with a release
<headius>
yes, and that is why the official JRuby image for 17 can't be based on the "openjdk" image anymore
<headius>
pushing these things to Docker is pretty easy, but I don't want to permute the world
<enebo[m]>
yeah
<headius>
but then we don't want the only image to be based on 18-tip
<headius>
so we have to choose someone's "official" builds of 17-latest, 11-latest, etc
<headius>
and that may be temurin for all I care
<enebo[m]>
yeah so there is maybe two things here
<enebo[m]>
1. older versions
<enebo[m]>
2 current version
<headius>
right
<enebo[m]>
having them be based ondifferent releases may also be strange
<enebo[m]>
For older versions it seems whatever is the latest acknowledged point release (which largely I think is just security releases) we want to pick something which actually will keep giving that
<enebo[m]>
openjdk appears to not be that right?
<headius>
correct
<enebo[m]>
So seems simple to say not-openjdk for that but then we say what do we pick
<headius>
right
<enebo[m]>
I think we just pick most popular thing
<headius>
Temurin, being first to the game as AdoptOpenJDK seems like the one
<enebo[m]>
but then for current version is there a significant downside to picking temurin for that?
<headius>
well, I guess I don't have a good answer to that
<enebo[m]>
We need to ignore employement or other considerations and just think about being a OSS resource-limited project
<headius>
is there any reason to base an image off the openjdk namespace if it can only be tip
<enebo[m]>
I think there are two things for this as well
<headius>
FWIW Georges thinks the Docker model of layering your crap on top of other people's crap is a bad model
<enebo[m]>
one is process for updating one thing versus different things
<headius>
I can't really disagree since supporting everyone's favorite base image means we have to permute Dockerfile for every one
<enebo[m]>
two is how likely we are to get issues reported or complaints that we are no releasing images of X
<headius>
we got requests for 17 before 17 was even out
<headius>
I don't know that we have had any or many requests for updated 11 images though
<enebo[m]>
so does this mean openjdk is the only game before the official drop?
<headius>
what do you mean
<enebo[m]>
well I just mean 18 went stable last week (I think) but not out yet
<headius>
18 is out
<enebo[m]>
is there still a temurin build of that even though it is not quite out yet?
<enebo[m]>
oh heh...well you get the question
<headius>
yeah why use "openjdk" baseline at all if we can get latest from "temurin" just as easliy
<headius>
why confuse by having the second set of images
<enebo[m]>
that is essentially where I am going here
<enebo[m]>
it is the same code but the people making the package and perhaps some supplementary things could be different
<enebo[m]>
if byteit101 had his way we would be imaging zulu 😀
<headius>
I guess my only justification would be something like... we will push builds based on temurin 8, 11, 17-latest, and if you don't like temurin there's an image based on openjdk-latest or you can build your own
<headius>
so in that way the jruby-openjdk builds would basically be latest non-LTS always
<headius>
and the temurin builds would be LTS releases
<headius>
that would cover folks requesting 18 images or 19 images without "choosing" temurin
<enebo[m]>
yeah I guess I don't know the value to people who want this needing openjdk-specific images
<headius>
and when the next one comes out the jruby-openjdk image will track that and move to 19 or 20
<headius>
yeah the misnomer here is that the "openjdk" namespace doesn't really mean "official openjdk builds", it means "free for use Oracle JDK builds of latest OpenJDK release"
<enebo[m]>
but there is a point I see here that image changes is not neccesarily based on our releases by itself but also by then something is LTS
<headius>
this is why the Docker folks urged everyone to stop using the openjdk namespace at all
<enebo[m]>
This means if we release JRuby 9.4 and it supports 11, 17, and latest we really have to potentitally update 3 things
<enebo[m]>
This all bugs me a bit as well. The container stuff really pushes a lot of small cuts on release
<headius>
not quite... we don't pin the version of base image in our dockerfile, so as long as 11 and 17 are pointing at temurin and "jruby-openjdk" points at latest "openjdk" image, we have two LTS and one tip image
<headius>
it does
<headius>
and everyone rolls their own Dockerfile generator to deal with this nonsense
<enebo[m]>
ok but we still need a container for 11, 17, and latest we just don't need to change config
<enebo[m]>
for the java part
<headius>
right
<headius>
the LTS-JDK images for JRuby will be based on Temurin because we say so, and the tip image will be based on latest "openjdk" image
<headius>
in my model
<headius>
so if you want bleeding edge openjdk, use jruby-openjdk and ride the walrus
<enebo[m]>
well I guess I don't care all that much since I think this will just be more documentation and a different tab open
<headius>
otherwise use "jruby" and we chose temurin for those
<enebo[m]>
but it is more complexity but as I said above it is a small cut of complexity
<headius>
I'm fine maintaining this
<headius>
I did not want to maintain a permutation of every commercial JDK
<enebo[m]>
Also I have not been doing this but it is just an extra step even though the number of images is the same
<enebo[m]>
So long as it is an instruction to follow it is ok
<headius>
FWIW the instant I tweeted that we will switch the JRuby images to Temurin I heard from every other vendor about why we should use their builds
<headius>
so I need a good answer for that
<enebo[m]>
If this makes people happy then I guess it is a bonus but I try to focus more on what we can support without adding work
subbu has joined #jruby
<enebo[m]>
well you could just not bother to tweet about it
<headius>
I am not clear if that is because they like the marketing aspect of having the JRuby images based on their builds, or if it is because they know their users will want a JRuby image based on their builds
<enebo[m]>
of course if you publicly say it then it invites the opporuntity
<enebo[m]>
I just don't think most JVM vendors are following our deployments too closely
<headius>
well, it needs to be announced somewhere that we are no longer supporting JRuby based on openjdk-17 or -11 images
<headius>
and those images are switching to temurin because we say so
<enebo[m]>
@jruby and temurin because it is most downloaded
<headius>
I do wish there were some official unsupported builds directly from the openjdk org but there just isn't
<enebo[m]>
it seems like a pretty good argument that the more people who use a particular image will be less put off by using the less popular image
<headius>
yeah and I don't quite get why it matters... anyone who has a specific blessed JDK image in their company can just add two lines to a dockerfile to install JRuby on that image
<headius>
I wish Docker itself had better support for defining the overlay without specifying a base image
<enebo[m]>
yeah to me this feels like a loud twitter issue at best
<headius>
our docker files are identical other than the base image, which is a big smell to me
<headius>
what value are we adding
<enebo[m]>
Of course people want to do zero work but we are not going to image all JVMs for them
<headius>
right
<headius>
so we choose one, and we choose temurin based on various factors
<headius>
and here's the dockerfiles so you can make your own
<enebo[m]>
This is also why I feel like just picking a single one for all makes the decision feel like we are just picking a "winner" or sorts
<headius>
yeah
<enebo[m]>
like if you have an app which runs on 11, 17 and current would you be put off that current is packaged by openjdk and not temurin
<enebo[m]>
The obvious reply to that complaint is make your own image if you care
<headius>
right
<enebo[m]>
but if I could rule the java world I would make all people use their own containers
<headius>
yeah I don't understand why docker hub isn't a repository of the overlays rather than the fully build stack
<enebo[m]>
I do think it is interesting that we are expected to support LTS images for JVM for JRuby but openjdk feels that is too much for them
<headius>
like here's the Dockerfile snippit to add JRuby to any JDK baseline, and you pull temurin-17 + jruby-9.4 and have it assembled
<headius>
instead you have to have a full Dockerfile built and pushed somewhere
<enebo[m]>
Devil's advocate would be if they can get away with that why can't we?
<enebo[m]>
but even in my head it is because people do want latest version of LTS to test against
<headius>
right
<headius>
Georges actually said "maybe you guys should only support latest JDK always and people can pay for earlier versions"
<enebo[m]>
and just imagine there are people out in the world using containers of openjdk in production (FOR SURE).
<headius>
we don't really "support" anything, but we "expect it to work" on these specific older versions
<headius>
so how "official" are our images, really
<enebo[m]>
support is softer for us than them
<headius>
right
<headius>
so how far into deploying images does that "support" extend
<enebo[m]>
but they do patch for CVEs...they just don't make an image with them 😀👀
<headius>
I feel like cutting off 11 and 17 images is premature, so we have to choose a reliable baseline for them
<headius>
yeah exactly
<headius>
if we wanted to be hardcore we would just say "jruby image is based on latest openjdk always" and people can live there or build their own
<enebo[m]>
There decision tree is even simpler than ours since they only make a decision about making an image for a new release JVM which they are making binary bits for
<headius>
right
<enebo[m]>
but I imagine they do a ton of verification we obviously don't
<enebo[m]>
So I am not roundly criticizing as much as thinking we are trying to accommodate more
<headius>
we are, but we need it to be a feasible amount o fmore
<enebo[m]>
yep
<headius>
8, 11, and 17 from temurin for the "jruby" images and latest from openjdk for the "jruby-openjdk" images seems ok to meet folks halfway
<headius>
and if you want Bob's Shiny JDK as your baseline you make your own
<enebo[m]>
so if you want to temurin for LTS 11,17 and say it is just the popular one...we roll with that...but we use Temerin or openjdk for current (I don't care as much past just sayign temurin seems simpler) then this seems reasonable to me
<enebo[m]>
Seems like we came out approximately in the same place
<headius>
ok
<enebo[m]>
I think less people see @JRuby than @headius so I would only announce there and probably not bother to RT from your account :)
<headius>
hah sure
<enebo[m]>
Largely I mean Java people
<headius>
a wiki page describing our justification and how to make your own images perhaps
<enebo[m]>
These are people who don't care about JRuby but do care about their favorite distro of the JVM
<enebo[m]>
yeah possibly just added to FAQ page but we do have an image wiki entry
<headius>
I will also look into how quickly temurin puts out images for openjdk-head... they may lag which would be enough justification to base our head image on "openjdk"
<enebo[m]>
yeah good point if so
<enebo[m]>
I have to think head builds probably are regular and automated in some way
<enebo[m]>
but perhaps not
<enebo[m]>
I almost wonder how different deployment of this even is. The diaspora of build engineers from Sun probably means many of these images all are the same
<headius>
they can't be very different
<headius>
so it is just marketing and politics
<headius>
and for users, it is whoever you want to get your JDK support from
<headius>
that's not for us to decide, but we need baseline images to play with so we chose temurin
<enebo[m]>
The other thing we didn't talk about really and shouldn't is that we don't actually even support these images
<headius>
right
<headius>
they are just convenience
<enebo[m]>
People using these for production are probably not doing it right
<headius>
we recommend you build and support your own image based on your blessed stack
<headius>
yeah
<headius>
or write us a check and we'll push images for your distro
<headius>
a big check
<enebo[m]>
in that sense people saying we need to provide unsupported X for them beyond using it for testing are probably not just using it for testing
<headius>
right
<enebo[m]>
I just don't think Azul gives a fuck if we are making images using their JVM. JRuby is a project a bunch of people use but it is not Maven
<headius>
yeah
<enebo[m]>
(my mind went blank on a pervasive huge OSS JVM project :) )
<headius>
the fact that we push something based on temurin is almost irrelevant, since you should be picking your preferred vendor and making your own image for production use
<headius>
ok so I will proceed with that then
<enebo[m]>
yeah exactlyu
<headius>
the other update is from the gRPC/protobuf chat I had with Jason Lunn
<enebo[m]>
so painters will be scraping and blasting our house tomorrow
<headius>
short update: they are reimaging almost all of the published libraries based on FFI, like I suggested they do 5+ years ago
<headius>
reimagining
<enebo[m]>
tonight I will be cutting all the weeds down around the base since they want to make sure they get all the paint (potential for lead in 117 year old house is high)
<enebo[m]>
but this is panama right?
<headius>
so it will be a moot point if that experiment works out and we won't have anything custom for JRuby in gRPC gem
<enebo[m]>
oh sorry I missed a sentence
<enebo[m]>
ok
<headius>
Jason actually wanted confirmation that he'd be deleting all of the C extension code because none of it is needed anymore with FFI
<headius>
so we will let that process move forward
<enebo[m]>
yeah
<headius>
ok I have to run
<enebo[m]>
ok me too
<headius>
ttfn... I'll be working on and off from MI
<enebo[m]>
ok
<enebo[m]>
9.2 and 9.3 issues when you hack so we can release when you get back
<headius>
byteit101: I have not had any time to figure out python issue, but that might be something I can poke next week