Hey everyone, 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.
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. 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. 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>". Any opinion about this? Any good or bad experience using those parameters to move build records and/or workspaces somewhere else on the disk? Thanks! 2018-03-14 18:55 GMT+01:00 R. Tyler Croy <[email protected]>: > (replies inline) > > On Wed, 14 Mar 2018, Baptiste Mathus wrote: > > > Hello everyone, > > > > For Jenkins Essentials > > <https://github.com/jenkinsci/jep/tree/master/jep/300>, one critical > > requirement is to be able to upgrade, and hence rollback in an automated > > manner. > > So, as we are committed to an open design > > <https://github.com/jenkins-infra/evergreen#open-design> process, I have > > written a first draft of the associated Jenkins Enhancement Proposal. > > > > It is up for review at https://github.com/batmat/jep/pull/1 > > > > I am very eager for any kind of feedback there. > > I am especially interested in catching & clarifying (more or less) > glaring > > holes in that design. > > > Thanks for taking the time to send this out Ba(p)tiste! Now that I've had a > chance to take a look, I think the one thing that's missing from this > document > is a bit more explanation of the problem which requires this solution. > > My take on this problem space is that core and plugin upgrades can result > in > modification of config.xml and other object-serialized-files on disk when > an > upgrade occurs. As these files are serialized from objects in memory, when > an > internal API changes within a plugin/core, it will necessarily result in > changes to files on disk. These changes may not be safe to "rollback" from, > i.e. Plugin A v0 cannot load a file generated by Plugin A v1. > > This means an upgrade of Jenkins Essentials has a very real potential to > cause > irreversible modifications to files on disk which prevent a safe rollback. > > > So that type background/context is (IMHO) missing a bit from the JEP > document. > > I think the Motivation section should also explain a bit more explicitly > that > "bricking" a Jenkins Essentials instance is a severe failure for the > project, > and thus we need to prevent against irreversible modifications to files > causing > runtime failures for the Jenkins Essentials installation. > > > Overall, I think this looks quite reasonable. I look forward to seeing the > implementation and tests we get to write to support it :) > > > 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/20180314175527.yeofyld6a2d2p4ro%40blackberry. > coupleofllamas.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/CANWgJS55C%2BPD0S9UG%2Bj6nr4H_dkisDQ2ODQY%2BkvZpXkC52WVUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
