-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reserved resources available again after reloading CasC configuration #527
Comments
This is not a bug. This is how the JCaC works. It will reload stored configuration. Independed of the status. I do not know, how can be changed (and if we really want). What you can do, is to set the reserved status in the yaml. Then it will be reserved also after reload. But I am not sure, if you want it. And it might be dangarous. JCaC his helpfull when you start your Jenkins in docker image, or you want to have transparent configuration (using with some source code management ...) And change like this, might broke Jenkins reboots. |
I'd like to throw in my agreement with @meeusen It makes sense for some aspects of locks to be controlled via CasC: the existence or not of the lock itself, descriptions, labels, etc. But it makes no sense to keep transient the state of the locks (locked or not) in the CasC. In our experience, the fact that this plugin loads the lock states from the CasC files makes it incompatible with Jenkins CasC which is a pain for shops relying on CasC for persistent configuration of Jenkins. Please consider not keeping transient information about locks in the CasC files. |
Basically, if you have configured your Jenkins with JCasC configuration, then you lose the reservations and the notes whenever Jenkins restarts or you reload the config. I think it comes down to that. I'm only just starting out with JCasC, but I see it as a replacement of the normal configuration in the UI, where it would behave in the same way. When you add a new resource in the UI, other resources that were reserved, are still reserved, and there is specific code in the plugin to make this possible. When you add a new resource to a JCasC YAML file and reload the config, I would expect the same to happen. That would be, for us, the main benefit of using JCasC, to make it easier to add/manage resources (which is cumbersome through the UI if you have many, especially if you want to order them in a specific way), while not interfering with users that have reserved a resource at that time. If a user wants to unreserve all resources when reloading the config, maybe they can explicitly set an empty "reservedBy" in their YAML file. On the other hand, I would prefer for the "reservedBy" to be removed from the UI settings, as it can interfere when adding new resources, basically what is described in #143. But that's more because of a problem with the UI configuration page, so that could be a reason to differ from the JCasC configuration behaviour. With your example about the Jenkins agents. The labels will be updated, but the executors that are running on that agent, will still keep running when you reload the config (I suppose). |
FYI: This was done a long time before I start with this pulgin. |
We encountered the same issue as @meeusen just now. While I agree that recreating the resources without the locks (and other post-CasC attributes) is technically what is supposed to happen, it can be quite disruptive. Would you consider an additional flag in the JCasC configuration to preserve locked/reserved resources acceptable? |
I am not sure if the flag is necessary. @imarkov-storpool do you want to try that? |
Just to confirm, do you mean I should make it so that locked/reserved builds are not touched at all by CasC? The point of having a flag is to preserve the current behaviour (since it is technically correct) by default. |
I mean, we can set the property reserved by as transient and remove it from the config page as well. Because it leads to buggy scenarios. |
+1 for this feature request. |
No, currently no workarround. My whish scenario: When there are no more open discussion, I will change it as describe here |
A common scenario in our Jenkins env: |
exaclty, but you as admin, never set the reserved "property" in JCaC . And does not see any reason to do that. Therefore I will remvoe this possibility and that´s it ;-) |
I agree, I don't think the I would like to be able to create lockable resources in JCaC but only the name, label and description. Users/pipelines can reserve or unreserve these resources but if Jenkins was restarted or the JCaC reloaded then the lockable resources should stay in the same reserved/unreserved state as they were before the restart. |
reopened - see also #650 |
Jenkins and plugins versions report
Environment
What Operating System are you using (both controller, and any agents involved in the problem)?
Fedora 37
Reproduction steps
Expected Results
The first resource should still be reserved, the other should still have the note.
Actual Results
The first resource is available again and the note of the other resource has been removed.
Anything else?
As the status (reserved/free...), timestamp and the note or not really configuration properties, but more state properties, should they not be kept when reloading the CasC configuration? For the classic configuration in Jenkins (Manage Jenkins -> System), this works fine when e.g. adding resources (or just changing something else in the System settings). I think this is done with a call to copyUnconfigurableProperties() in https://github.com/jenkinsci/lockable-resources-plugin/blob/master/src/main/java/org/jenkins/plugins/lockableresources/LockableResourcesManager.java#L980.
The text was updated successfully, but these errors were encountered: