Where are logs stored (temporarily for the main log as I assume (wrongly) some logstash pump type service)?
Both access logs (these should be configured OOTB but are not as of today), and Jenkins logs, and any custom logs (currently $JENKINS_HOME/logs/? I do not think these should be "lost" if you roll back - as you loose information about what happened between the upgrade and the rollback - which could be very important as you really want to know why it got rolled back... /James On Thursday, March 15, 2018 at 2:48:36 PM UTC, Baptiste Mathus wrote: > > 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] > <javascript:>>: > >> (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] <javascript:> >> >> % 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] <javascript:>. >> 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/7cad8dc8-ef03-4781-ab94-294027491d60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
