Description
On older versions on Jenkins Operator, we are able to set a PVC for the $JENKINS_HOME directory and persist everything across Jenkins Pod restarts, Node restarts, catastrophic cluster failure etc, just by copying the folder.
On the latest version of Jenkins Operator v0.8.0, here's the below snippet for Backup & Restore :
Because of Jenkins Operator’s architecture, the configuration of Jenkins should be done using ConfigurationAsCode or GroovyScripts and jobs should be defined as SeedJobs.
and also :
Note on restricted Jenkins controller pod volumeMounts
Current design of the Operator puts an emphasis on creating a full GitOps flow of work for Jenkins users. One of the key points of this design is maintaining an immutable state of Jenkins.
One of the prerequisites of this is an ephemeral Jenkins home directory. To achieve that, Operator mounts emptyDir Volume (jenkins-home) as Jenkins home directory. It is not possible to overwrite volumeMount and specify any other Volume for Jenkins home directory, as attempting to do so will result in Operator error.
This means that if we install 10+ plugins with various configuration settings, the GroovyScripts will be huge and highly complicated to begin with, not to mention we have to put it in a ConfigMap on Kubernetes which makes maintaining all of them even messier.
With this new architectural decision, you have effectively increase the learning curve of anyone who wants to deploy/migrate Jenkins on Kubernetes by multiple folds, and blocking any productive work unless one master the Groovy CaaC. Not to mention many core users & SMEs are using it with only 2 things in mind, manage CI pipelines and persist data, and then only move on to more complex stuffs.
Don't get me wrong I think the Operator pattern still merits a lot of good work from you guys and I understand the architectural decision from a technical standpoint, but by killing the benefit of an simple starting up, you risk businesses & cloud-native users moving to easier and friendlier alternatives.
Will be there a possibility of keeping the legacy $JENKINS_HOME data directory for now and allow user to assign a PVC to it ? At least until there is a better Operator documentation and quickstart.
Relevant links Link(s) to the section(s) of documentation that are outdated or otherwise wrong https://jenkinsci.github.io/kubernetes-operator/docs/how-it-works/architecture-and-design/ https://jenkinsci.github.io/kubernetes-operator/docs/getting-started/latest/installing-the-operator/
Description On older versions on Jenkins Operator, we are able to set a PVC for the $JENKINS_HOME directory and persist everything across Jenkins Pod restarts, Node restarts, catastrophic cluster failure etc, just by copying the folder.
On the latest version of Jenkins Operator v0.8.0, here's the below snippet for Backup & Restore :
and also :
This means that if we install 10+ plugins with various configuration settings, the GroovyScripts will be huge and highly complicated to begin with, not to mention we have to put it in a ConfigMap on Kubernetes which makes maintaining all of them even messier.
With this new architectural decision, you have effectively increase the learning curve of anyone who wants to deploy/migrate Jenkins on Kubernetes by multiple folds, and blocking any productive work unless one master the Groovy CaaC. Not to mention many core users & SMEs are using it with only 2 things in mind, manage CI pipelines and persist data, and then only move on to more complex stuffs.
Don't get me wrong I think the Operator pattern still merits a lot of good work from you guys and I understand the architectural decision from a technical standpoint, but by killing the benefit of an simple starting up, you risk businesses & cloud-native users moving to easier and friendlier alternatives.
Will be there a possibility of keeping the legacy $JENKINS_HOME data directory for now and allow user to assign a PVC to it ? At least until there is a better Operator documentation and quickstart.