@astepano this seems like a regression from the previous deployment when we expected to lose changes after redeployment. Do you know how to disable the auto-reload for now?

I doubt that disable jcasc is good idea.
If you want to experiment - I can deploy a new stage Jenkins with disabled jcasc (that is not wired with prod authorization).
Prod Jenkins should use jcasc.
Otherwise, we will loose track of necessary changes.
We want to escape fate of https://jenkins-continuous-infra.apps.ci.centos.org/
If you know which changes you want to apply permanently, please open ticket.
(This is my opinion)
Adding @bookwar @jimbair to express their opinion.

I am all for JCasC, but only when we have established process around it. Correct me if I am wrong, but currently we don't have any repo where the configuration lives, we don't have docs, and we don't have docs around redeployment (?). It seems to me that it's way too early to start enforcing JCasC :) Opening tickets for everything while things are under heavy development doesn't seem like a good idea to me.

At minimum, I'd like to be able to modify things I need directly - to be able to iterate quickly. I don't mind doing it in JCasC from the beginning, but not via tickets. Just my .02 (euro)cents :P

It is better to follow the process from the beginning.
It is much better then write 1 huge yaml file in the future
I can share current yaml files (actually for centos cluster it is already shared, for osci-jenkins-1.ci.fedoraproject.org I wrote it today)..
But, the process would be the same: change to it and deploy with tickets or git-commit.
There is doc how to access AWS EKL if you want it to do by your self.
Also I am always ready to help and deploy new changes.

Point is: post-writing yaml for master configuration to comply all existing prod jenkins-jobs will be not pleasant task.

Disabled as requested by @bookwar and @msrb