Hello, As a Jenkins User, I've run instances in production or punctually (workshops) with the "plugins" directory into a RAMDISK without issues. When the persistence was required, I use to migrate this to a "machine local directory" (generally hypervisor local disk) to avoid having it stored on the NFS or the SAN used for Jenkins_home.
@Baptiste, I understand the concern about Evergreen. Obviously a trade-off will be in this specific case. Let's say you declare it as a separate volume in the initial Docker image, what would be the impact for the end user? My point here is to use the Docker "VOLUME" instruction to give a good default implementation, but without having to bother the end user: Docker ill take care of creating a dedicated data volume for this. It will ensure a fairly good default performance (if Docker's data volumes are slow, then the plugins directory will be the least of your concern :) ), and will work everywhere (Docker will take care of creating the volume at initial startup). Also, advanced Docker users would be able to tune it if they have specific needs. But it will still be a different VOLUME in the Image's metadata, expressing the different persistence properties. What do you think? Le lundi 26 mars 2018 11:19:52 UTC+2, Baptiste Mathus a écrit : > > For context, I asked Sam to come and discuss this here after his comment > <https://github.com/jenkinsci/jep/pull/67/files/6773edbc06488de4c2fa7371f54c79df38672861#r176294065> > > on the JEP about Essentials Evergreen snapshotting system, in the part > where we explain how we plan to aggressively segregate data > <https://github.com/jenkinsci/jep/tree/master/jep/302#data_segregation>. > > So, my take is going to be two-fold: > > > - On Essentials, I think we are free to do more things because we have > basically no existing setup. So I'm leaning towards doing this. > I'm just slightly worried about: > - Bad performance (though heavily depending on the storage driver) > writing things in a layer that could grow pretty big outside the > $EVERGREEN_HOME volume. > - At the same time, this would also be a good thing® since by > definition this would be cleaned up if someone starts with a fresh > image > version (though it's not *really* the use case of Essentials, as the > content will auto-update) > - we could also have a second volume dedicated to writing > caches, but I'm not very keen on doing that since I feel this would > go > against the evergreen idea to be very simple to use. And users would > probably have to manage the data written in that second volume > instead of a > single one (which I suppose people are more used to see). > > - For Jenkins packages, I think this would be a good thing to do > to, it's just that it's clearly more complex to do since there are > existing > setups out there. So we'll want to make sure we don't break people > instances when upgrading after such a change. > > > > 2018-03-24 1:29 GMT+01:00 Sam Gleske <[email protected] <javascript:>>: > >> I normally store expanded plugin metadata within >> /var/cache/jenkins/plugins similar to how WAR filre metadata is stored in >> /var/cache/jenkins/war. >> >> Is there any particular reason the Jenkins packages don't do this? Are >> there any drawbacks? I'm curious if others have any opinions on this. >> >> I've been running Jenkins quite a while like this. >> >> [1]: >> https://github.com/samrocketman/jenkins-bootstrap-shared/blob/1a409cad89007f56ed36342427b767dd4e88fbd9/packaging/docker/run.sh.in#L38 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/05beb1e5-a824-428c-b980-07a4e343acdc%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c2e92766-3007-4723-920a-8a9773b3055b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
