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.

Reply via email to