Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

jonsten
Copy link
Contributor

@jonsten jonsten commented Jan 8, 2020

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.

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.
Copy link
Member

@oleg-nenashev oleg-nenashev left a 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?

@jonsten
Copy link
Contributor Author

jonsten commented Jan 8, 2020

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.

I am requesting changes, because the new option needs to be documented in README.

Definitely I'll fix!

Javadoc for the new property

I'll fix!

New Static Getter method. It will be useful for Dwnstream plugins, because they can optimize their logic when fingerprint recording is disabled

Shouldn't they be able to use the field directly or that is a no-go way to solve it?

@oleg-nenashev
Copy link
Member

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

@jonsten
Copy link
Contributor Author

jonsten commented Jan 8, 2020

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.

@jonsten jonsten requested a review from oleg-nenashev January 8, 2020 10:50
@@ -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;
}
Copy link
Member

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?

Copy link
Contributor Author

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).

Copy link
Member

@oleg-nenashev oleg-nenashev left a 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.

@oleg-nenashev oleg-nenashev requested a review from jglick January 8, 2020 14:40
Copy link
Member

@jglick jglick left a 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.

@jonsten
Copy link
Contributor Author

jonsten commented Jan 8, 2020

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.:

def image = docker.image('some_image')
image.inside {
    ...
}

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.

@jglick
Copy link
Member

jglick commented Jan 8, 2020

@jonsten
Copy link
Contributor Author

jonsten commented Jan 8, 2020

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.

@oleg-nenashev
Copy link
Member

@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

@jglick
Copy link
Member

jglick commented Jan 8, 2020

I do not think other plugins produce Docker fingerprints. Anyway the request here was about docker-workflow.

@jonsten
Copy link
Contributor Author

jonsten commented Jan 9, 2020

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)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants