On Mon, Oct 1, 2018 at 6:51 AM nicolas de loof <nicolas.del...@gmail.com> wrote: > we just don't need to wait for a new jenkins-core release, this can be > adopted without delay.
If I understand your proposal correctly, you suggest that a sidecar container fetch cloud-native configuration (say, K8S CRDs) as an initialization task and save it into `$JENKINS_HOME/**/*.xml` in traditional XStream format that unpatched Jenkins cores can read. This is certainly something to consider seriously, as it would involve much compatibility concerns that existing proposals, and the volume of configuration files is small enough that we are not concerned about the I/O implications of mirroring solutions (unlike other cloud-native storage problems such as artifacts and logs). Then the issue becomes synchronization of dynamic changes. For cloud → Jenkins we can assume that detecting changes on the cloud side is easy enough, and we can overwrite XML files on the shared drive, but how to notify Jenkins that we should reload just that file? Currently there is no such general system in Jenkins: you can make (REST) API calls to reload a particular `AbstractItem`, or the system (`Jenkins`) as a whole, but not necessary a single `GlobalConfiguration` or the like. For the other direction, the sidecar could watch for changes to files it manages and mirror them to cloud storage. Can a K8S container rely on the existence of inotify, or does it need to poll? Or can we just look for changes after the pod shuts down? -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr23jhgArVCzGUq9uM0rvWwLG4VaBt-3LUEzirpWWcp5BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.