(replies inline) On Thu, 15 Mar 2018, Baptiste Mathus wrote:
> I thought I'd start a dedicated email here about that part after some > feedback I got in https://github.com/batmat/jep/pull/1. > I know people are very busy so maybe an email is easier for many than > looking at the PR. Thank you for bringing this discussion back to the jenkinsci-dev@ mailing list, I think this will give more people to an opportunity to weigh in and consolidate our discussions into threads for easy linking in the JEP "References" section. More below.. > So the one the ideas I have for Essentials' data snapshotting system is to > use the configuration parameters to put builds and workspaces under a > single and non default root > <https://github.com/batmat/jep/blob/03d3404aba079b2f9b67284f6fc9940bf2ccfacd/jep/302/README.adoc#segregate-job-configuration-and-build-data> > . > > Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME* > (instead of everything under *jobs* as it is usually): > var/ > ????????? the_job > ????????? builds > ??? ????????? 1 > ??? ??? ????????? build.xml > ??? ??? ????????? changelog.xml > ??? ??? ????????? log > ????????? workspace > jobs/ > ????????? the_job > ????????? config.xml > > Jesse <https://github.com/batmat/jep/pull/1#discussion_r174508332> and James > <https://github.com/batmat/jep/pull/1#discussion_r174472740> are even > saying we should move the var directory somewhere else *not* under > JENKINS_HOME. I cannot say I have ever intentionally moved /jobs/ around in this manner, I assume that it "just works" and there's no quality concerns we should have from a non-standard placement of data on disk? Otherwise I have no problems with this. > Also, saying that we should not even (try to) put the builds (and workspace > I assume) in the Git repository, since it is not scalable. >From my understanding of the potential failure scenarios with a plugin or core upgrade is that unreadable build.xmls won't present a problem, or be mutated by a new plugin update, correct? If that's the case then I don't see a problem with leaving them out of the snapshotting system. Generally speaking, I believe we should be mostly tracking data which will be mutated on upgrade, or other potentially high importance data. > I'm in mind to adjust the JEP with that proposal, though it somehow > conflicts with that statement in the JEP-301 that "all mutable state and > data will be written and stored in JENKINS_HOME > <https://github.com/jenkinsci/jep/tree/master/jep/301#mutable-data>". When I wrote `JENKINS_HOME` I was actually just using that as a short-hand for what is commonly understood as `/var/lib/jenkins` to most people. Basically, 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 long as we're mounting everything through a single volume mount for the container, my concerns/requirements for JEP-301 are met. Does that make sense to you Ba(p)tiste? Cheers - R. Tyler Croy ------------------------------------------------------ Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> xmpp: [email protected] % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F ------------------------------------------------------ -- 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/20180315162720.ce7bbd67l2lu6yaz%40blackberry.coupleofllamas.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
