On Thu, Jan 24, 2019 at 11:32 AM Tomasz Sęk <[email protected]> wrote: >>> make backup of jobs history before Jenkins master pod deletion and restore >>> it in new pod > >> You do not just set a custom build record directory […] and use a persistent >> volume claim? […] >> Beware however that there is some more true state besides >> build history; it is safest to persist the entire `$JENKINS_HOME`, and >> let JCasC + `job-dsl` overwrite old configurations. > > Making backup of ~50GB is not good idea. […] Backup is triggered before > Jenkins master pod deletion and it have to be quick as possible.
Which is why I suggested a PVC rather than a backup per se. Anyway the vast majority of the disk usage in `$JENKINS_HOME` is likely to be build records (`*/jobs/**/builds/**`), especially if you are not using any of the other “pluggable storage” features mentioned in the SIG to externalize big files like artifacts or logs. Or do you mean something else by “jobs history”? > plugins are separated in two groups: required by jenkins-operator(used to > configure Jenkins)(A) and required by user(B) I would agree with Nicolas here that you should not use Jenkins code to manage installed plugins. (You can mandate the inclusion of some minimum version of certain plugins, such as `configuration-as-code`, known to be needed for managing _other_ configuration.) > we have to run some jobs on master to configure it(apply grovy scripts, > restore/backup and seed jobs creation). This seems inadvisable and is generally insecure. Better for these tasks to be externalized. (In the case of the `job-dsl` plugin, no master executor should be required as it runs in-process. That in itself is a major headache and we ought to prefer systems which run externally.) > We had problems when Jenkins master goes down and JNLP agent try to reconnect > and it fails after timeout. Maybe increasing timeout in agent could solve > this issue. Yes, that could be. > My idea: > - Jenkins master goes down > - disconnect all slaves from the master > - perform new backup > - spin up new master > - configure it, restore backup > - reconnect slaves to new Jenkins > - Jenkins will resume builds from old Jenkins Yes, this is what works today without any particular issue. I thought you were referring to a scenario in which two masters would be running at once, which could not be supported without major surgery. -- 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/CANfRfr3EPxgGR1Xoi1_123xyvMhr9zW31C4dsKN50%2B7hwPCyZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
