-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to add libz to the tiny runtime image #79
Conversation
At the last working group @ryanmoran suggested that this should be a stacks sub-team RFC, which seems reasonable to me. |
I have moved this to the stacks subteam. @sophiewigmore @brayanhenao, your thoughts are appreciated. Thanks |
I think the main issue I am struggling with here is is adding something to Tiny that isn't needed by ALL of our Paketo Buildpacks, so that there's a superfluous package hanging out in the run image in some use cases. That being said, the fact that the addition is to enable Java, which makes up a non-trivial amount of Paketo use cases, as well as the small package size are compelling benefits. These benefits outweigh that one negative for me, so I am good with this. |
@dmikusa-pivotal I did some tests adding the I agree with @sophiewigmore, It's worth it this this small size addition to the image compared to the fact that will enable the use of Tiny in Java. |
Awesome, thanks to everyone for the feedback! |
Is this addition of this single package all that is required to run all Java workloads on Tiny? |
@fg-j - Yes, that's my understanding. I haven't actually tried it though. If there's a desire to try before we make the change & someone can provide a modified tiny image (or instructions how to add it), I can do that & report back. |
Personally, I'd love to see an exploration of that, or some prior art or documentation that indicates this package is all we'd need for Java on Tiny, since it's so painful to remove a package from a stack once added, but I'll defer to the Stacks maintainers. |
@brayanhenao Is the test image you created a tiny builder? Wondering if you could share & I could test this out? Thanks |
Steps to reproduce the addition of a package to tiny:
Eg: |
Thanks @brayanhenao I was able to build the tiny stack image with the additional library, create a builder from it, update the Java buildpacks to allow the tiny stack and package all those up. Then run against the maven sample & it builds. There is a small issue with it running, not the JVM itself. That is OK, but the jvm kill agent that we install doesn't run. There appears to be a different library required for that to work.
I am going to do a little more testing to confirm that is the only issue. If that's the case, after talking with @ekcasey, we'd like to continue forward for this. We can find a workaround, such as disabling jvm kill agent, until we can recompile it without that dependency. I'll update again tomorrow with the results of additional testing. |
OK, as suspected. Removing the JVM Kill agent will allow Java apps to run on the tiny stack. I'd like to move forward with this RFC, regardless of the JVM Kill agent issues. I think that's a minor problem, and we can fix it later without any more stack modifications. Please let me know if there's any additional concerns with this PR. |
@dmikusa-pivotal I don't know a huge amount about the JVM Kill agent, but I'd like to be 100% sure that there won't be anymore stack modifications needed to enable this before we go through with it. Every java sample app I have played with (not many, to be fair) has pulled in the JVM Kill agent. If it's a big part of the ecosystem it worries me that we need to solution around it. |
At the moment, the JVM Kill agent is always installed. I had to work around this by disabling it in a dev build to confirm that there are no additional libraries or impacts to running on the tiny stack. It's a hack at the moment, but just for the purposes of testing & validation. With those additional tests, I didn't find any more situations where there were failures. I didn't exhaustively test, but I tested some common scenarios which were all fine. In addition, beyond the JVM itself and the JVM kill agent, I do not believe we're installing any native code. The rest is all Java byte code, which doesn't care about the stack or native libraries. Given that the JVM kill agent doesn't work at the moment, there's a couple of options moving forward. None of these would require additional libraries installed into the stack.
Give the above info, my proposed plan is this:
That should meet the primary goal which is to get Java workloads able to run on tiny in a reasonable time frame. |
@dmikusa-pivotal thanks for the context, that plan seems reasonable to me. I didn't know that the JVM kill agent could be emulated with flags. I wonder if the use of those flags produces the same error as the one you saw with the agent? That could be an issue if so. |
To be clear, it won't get you 100% of what the JVM kill agent does, maybe 50-75% though, depending on exactly what features of the JVM kill agent you use. It will get you the most used parts though, being able to have a heap dump written on exit.
No, they should not. They are native to the JVM and require no extra shared libraries. |
* Assigns ID stacks/0002 to libz PR * Adds README for stacks RFCs * Removes rfcs subdir from text/stacks for consistency with other teams * Removes redundant template Signed-off-by: Emily Casey <ecasey@vmware.com>
@@ -45,6 +45,3 @@ Example: | |||
## Unresolved Questions and Bikeshedding | |||
|
|||
Is there a clearer/more accurate label name we can use? Technically "stack" refers to a pair of images but we're only trying to represent the packages on a single image. | |||
|
|||
|
|||
{{REMOVE THIS SECTION BEFORE RATIFICATION!}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanmoran Is this entire section intended to be removed? It seems we haven't been doing that consistently so I wasn't sure if that was still the intent.
@sophiewigmore and @brayanhenao I think we should at least remove these lines for now (cause they look kinda silly) and I can follow up with a PR to remove bikeshedding sections from every RFC if that is desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good with that @ekcasey
* Add `zlib1g` package to the tiny stack. Implements [Paketo Stacks RFC 0002](https://github.com/paketo-buildpacks/rfcs/blob/main/text/stacks/0002-add-libz.md) based on the conversation [here](paketo-buildpacks/rfcs#79 (comment)). * Updated README to include zlib1g Co-authored-by: Daniel Mikusa <dmikusa@vmware.com>
* Add `zlib1g` package to the tiny stack. Implements [Paketo Stacks RFC 0002](https://github.com/paketo-buildpacks/rfcs/blob/main/text/stacks/0002-add-libz.md) based on the conversation [here](paketo-buildpacks/rfcs#79 (comment)). * Updated README to include zlib1g Co-authored-by: Daniel Mikusa <dmikusa@vmware.com> Co-authored-by: Daniel Mikusa <dmikusa@vmware.com>
Summary
At the moment, Java applications do not run on the tiny builder. It is possible to build them, however, if you try to run one you'll end up with an error
libz.so.1: cannot open shared object file: No such file or directory
.Use Cases
Checklist