@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 <[email protected]>: > On Thu, Mar 15, 2018 at 12:27 PM, R. Tyler Croy <[email protected]> > 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 [email protected]. > 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 [email protected]. 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.
