@Jesse The alternative I had considered too was to just have multiple volumes. But I agree having only one is also more inlined with Essentials philosophy, having only one volume to actually backup (because yes, users should still backup, JENKINS-49406 is *not* a backup system) is simpler.
@James I agree with your comment on logs. - For Jenkins logs: unsolved yet, but we will have to dig into it very soon for JENKINS-49805, which is another critical part for the success of the project. I think if we go the way surfacing above, i.e. adding another level under $JENKINS_HOME to separate what is snapshotted, and what is not, we would kind of have a good place for those anyway. - For access logs: good point, though same, not enabled yet. I think we could also decide to use a reverse proxy for this purpose, since anyway we're likely to need to introduce that component so that users connected to Jenkins via their browsers see a breakage when Jenkins is restarting. Will adjust the proposal very soon with all this. Thanks a lot for your feedback, I feel we're progressively reaching a more decent thing together, which is always an intent for reviews. So that's great. Cheers 2018-03-16 17:26 GMT+01:00 Jesse Glick <jgl...@cloudbees.com>: > On Thu, Mar 15, 2018 at 12:27 PM, R. Tyler Croy <ty...@monkeypox.org> > wrote: > > I > > assume that it "just works" and there's no quality concerns we should > have from > > a non-standard placement of data on disk? > > Any obvious problems would have been reported long ago. (I remember > some fixes involving folder renames or something like that.) By > forcing Essentials users to run with this mode, we would quickly flush > out remaining corner cases, I would think. > > > From my understanding of the potential failure scenarios with a plugin > or core > > upgrade is that unreadable build.xmls won't present a problem > > Not that I am aware of. > > > or be mutated by > > a new plugin update > > It is possible for a plugin to mutate the `build.xml` of a completed > build, but unusual, and probably even less likely that such an update > would occur during Jenkins startup. > > > mutable state should not be scattered around inside the container's > temporary > > filesystem, but rather contained in the single mounted volume, e.g.: > > > > docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen > > So we could have a volume which contains `$JENKINS_HOME` as a > subdirectory, which would be the root of a Git repository; plus some > other subdirectories for other unversioned data. That makes more sense > to me than what was written in JEP-301. > > -- > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/CANfRfr3RUuod%3D5aqV2F_Hwu%3D1K%3DnVmM9a9VhvySVnccL-_ > mvpw%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6uckBBUkmUUWXP1c6yKw2hxzu%2BjkTApzYwnoHy2PEthQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
