-
Notifications
You must be signed in to change notification settings - Fork 76
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
Add ability to disable fingerprint recording #85
base: master
Are you sure you want to change the base?
Conversation
It seems like the fingerprinting functionality has been broken for a while and causes a lot of problems, especially in large Jenkins instances. This change introduces a property which disables the functionality all together.
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.
I agree with such approach in general. It would be great to disable Docker fingerprint recording. It might make sense to offer it as a Global configuration, but system property is acceptable as well IMHO.
I am requesting changes, because the new option needs to be documented in README.
I would also suggest adding...
- Javadoc for the new property
- New Static Getter method. It will be useful for Dwnstream plugins, because they can optimize their logic when fingerprint recording is disabled
- TBD - Web UI configuration options?
src/main/java/org/jenkinsci/plugins/docker/commons/fingerprint/DockerFingerprints.java
Show resolved
Hide resolved
Thank you for the quick feedback! I opted for the system property as it is the "quick" solution and it doesn't bloat system configuration with yet another checkbox. With that said I agree with you that this might be a rather useful setting. In fact, in a perfect world it should be possible to set from case to case, e.g. same way as it is done for artifacts. Unfortunately I'm not willing to spend the effort to implement all of that. I will see if there is a natural place to add a system config, if not I will go with the system property route.
Definitely I'll fix!
I'll fix!
Shouldn't they be able to use the field directly or that is a no-go way to solve it? |
It is also possible, but it will complicate further changes should we decide to change/improve behavior later (e.g. adding a global configuration). Static methods are more convenient from the extensibility PoV |
Got ya, I'll add a static method! As for global config, I see no natural home for such an option, so, let's start with the property for now. Adding information in the README and in code should be enough for people to find it if they start to run into performance problems. |
Base of review feedback.
@@ -221,6 +232,9 @@ private DockerFingerprints() {} // no instantiation | |||
* Adds a new {@link ContainerRecord} for the specified image, creating necessary intermediate objects as it goes. | |||
*/ | |||
public static void addRunFacet(@Nonnull ContainerRecord record, @Nonnull Run<?,?> run) throws IOException { | |||
if (DISABLE) { | |||
return; | |||
} |
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.
Would it also make sense to add logging on the FINE or INFO levels?
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.
I'm not the expert here, after all, I'm the one making a change to disable all of this, so I have a hard time finding a point where it would be useful. But if you can see a reason for adding it, I'll happily add it :) Besides, at level FINE/INFO it would require the user to actively set the log level in order to get it to the system logs etc (have it on by default would be way to chatty IMHO).
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.
All major comments are addressed, 👍 for merging
Besides, at level FINE/INFO it would require the user to actively set the log level in order to get it to the system logs etc (have it on by default would be way to chatty IMHO).
That's why it is FINE
. We do not want it to be printed by default, unless a deep dive needed for diagnostics.
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.
Should no longer be necessary as of jenkinsci/docker-workflow-plugin#180 in 1.19 plus jenkinsci/pipeline-model-definition-plugin#350 in 1.4.0.
Ummm okay, I've might have missed something, so please explain how I prevent fingerprint recording without this change when i run a scripted pipeline, e.g.:
With the latest release of docker common and docker workflow plugin this code will record fingerprints. Edit; Aha, I think I see it now, looking at jenkinsci/docker-workflow-plugin#180 it looks like inside command wasn't addressed. |
Yes https://github.com/jenkinsci/docker-workflow-plugin/blob/74a2370901f41e8b5b541d768b440e2ab1cd1b18/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L209 was forgotten, as were a couple lines in |
Okay, then it sounds like I could scrap this change and instead remove the call to addRunFacet in WithContainerStep. I'll see what I can do tomorrow. |
@jglick @jonsten I think this is still relevant, because there are other plugins relying on Fingerprints. E.g. DockerHub Notifications IIRC. Pipeline is not the only API where it is used. One of the follow-ups for the Docker Traceability project in 2015 was to improve fingerprints performance, but it has never happened as you may guess :( https://jenkins.io/projects/gsoc/2020/project-ideas/external-fingerprint-storage-for-jenkins/ in GSoC may somewhat address it |
I do not think other plugins produce Docker fingerprints. Anyway the request here was about |
Based on what @jglick bought up I've created jenkinsci/docker-workflow-plugin#198 over at docker-workflow. I've also added the log entries you suggested @oleg-nenashev. I leave it to you guys to decide which one to merge (or both(, or none)). |
It seems like the fingerprinting functionality has been broken for a while (e.g. see this comment by Jesse Glick) and causes a lot of problems, especially in large Jenkins instances. This change introduces a property which disables the functionality all together.
Some background, in our case, where we run 10k+ builds a day using the same docker image, the fingerprint file for that image grows very large 50+ MB and around 100k container entries. The large size causes Jenkins to spend more and more time saving the file (serialization, file IO, etc). In the end, when it gets large enough, the builds are aborted without anything being written in the logs (separate issue, but it seems like if more than five minutes is spent in the step start / fingerprint recording phase, then the build is terminated without anything written in the log). At that size it takes around 3-4 seconds to save the file, and if 100 builds are starting containers at the same time, then some of them will spend more than five minutes waiting.