[JIRA] (JENKINS-38906) Remove lock resource name from global configuration when lock is released

2 views
Skip to first unread message

ted@syapse.com (JIRA)

unread,
Oct 11, 2016, 1:10:01 PM10/11/16
to jenkinsc...@googlegroups.com
Ted Lifset created an issue
 
Jenkins / Improvement JENKINS-38906
Remove lock resource name from global configuration when lock is released
Issue Type: Improvement Improvement
Assignee: Unassigned
Components: lockable-resources-plugin
Created: 2016/Oct/11 5:09 PM
Priority: Minor Minor
Reporter: Ted Lifset

'Lockable Resources' within Jenkins global configuration can grow quickly when lock names are selected which are dynamically created and are transient in nature.

Would be nice to clean-up the global configuration when locks released by removing the named lock value.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

eeaston@ahl.com (JIRA)

unread,
Nov 15, 2016, 10:23:02 AM11/15/16
to jenkinsc...@googlegroups.com
Edward Easton commented on Improvement JENKINS-38906
 
Re: Remove lock resource name from global configuration when lock is released

+1. Alternatively, add a flag to the resource that marks it as 'transient' and so is not stored in the global config. Something like:

lock(name: 'my-resource', transient: true) {
   ...
}

pwolf@cloudbees.com (JIRA)

unread,
Dec 13, 2016, 5:30:01 PM12/13/16
to jenkinsc...@googlegroups.com
Patrick Wolf assigned an issue to CloudBees Inc.
 
Change By: Patrick Wolf
Assignee: CloudBees Inc.

amuniz@cloudbees.com (JIRA)

unread,
Mar 13, 2017, 3:19:04 PM3/13/17
to jenkinsc...@googlegroups.com
Antonio Muñiz commented on Improvement JENKINS-38906
 
Re: Remove lock resource name from global configuration when lock is released

Removing on release would not be safe. +1 for the transient parameter.

There should be a periodic background task looping on defined resources and removing those marked as transient and not used after a specific amount of time.

Also transient resources should not be displayed in the administration page as it does not make sense to configure them nor remove them.
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

amuniz@cloudbees.com (JIRA)

unread,
Mar 13, 2017, 3:20:03 PM3/13/17
to jenkinsc...@googlegroups.com
Antonio Muñiz assigned an issue to Antonio Muñiz
 
Change By: Antonio Muñiz
Assignee: CloudBees Inc. Antonio Muñiz

DTaylorBusiness@gmail.com (JIRA)

unread,
Jun 11, 2018, 5:57:03 PM6/11/18
to jenkinsc...@googlegroups.com
David Taylor commented on Improvement JENKINS-38906
 
Re: Remove lock resource name from global configuration when lock is released

Javier Delgado any luck getting that script to work as a jenkins job? I keep getting odd errors when trying to run it as a script. I can run it the script console but not as a regular job in the "Build" section. 

witokondoria@gmail.com (JIRA)

unread,
Jun 12, 2018, 2:09:06 AM6/12/18
to jenkinsc...@googlegroups.com

David Taylor, that script has been working as a pipeline job since 10/17, on several Jenkins instances and versions. Wont the "odd errors" related to metrods needed to become approved via the instance scriptApproval service?

mpaukkila@gmail.com (JIRA)

unread,
Jun 26, 2018, 10:37:03 AM6/26/18
to jenkinsc...@googlegroups.com
Mikko P commented on Improvement JENKINS-38906

In addition to retainAll, you can use:

def all_lockable_resources = GlobalConfiguration.all().get(org.jenkins.plugins.lockableresources.LockableResourcesManager.class).resources
print all_lockable_resources
{{all_lockable_resources.removeAll { it.name.contains("whatever_you_want_to_filter") }}}
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

mpaukkila@gmail.com (JIRA)

unread,
Jun 26, 2018, 10:38:02 AM6/26/18
to jenkinsc...@googlegroups.com
Mikko P edited a comment on Improvement JENKINS-38906

skeenan@gmail.com (JIRA)

unread,
Sep 6, 2018, 7:02:02 PM9/6/18
to jenkinsc...@googlegroups.com

Bump - curious if anything can be done about this.  Not having the ability to clean up locks that are auto-created seems like more than a "minor" priority...  this could quickly balloon out of control.

Thanks a lot for the cleanup suggestion Mikko P
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

svanoort@cloudbees.com (JIRA)

unread,
Oct 25, 2018, 8:09:07 AM10/25/18
to jenkinsc...@googlegroups.com

Vivek Pandey This one might be worth our team taking up, since locks are used rather heavily.

extermillenium@hotmail.com (JIRA)

unread,
Nov 7, 2018, 6:12:03 AM11/7/18
to jenkinsc...@googlegroups.com
Ricard F commented on Improvement JENKINS-38906

Same case here!!!!

Aaron.Marasco@BIA-Boeing.com (JIRA)

unread,
Nov 7, 2018, 7:05:02 AM11/7/18
to jenkinsc...@googlegroups.com

Using code from comments above, I have a Jenkins job that runs weekly to remove the ones that start with certain phrases:

// AV-4738 and JENKINS-38906
def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
def resources = manager.getResources().findAll {
    (!it.locked) && (
        it.name.startsWith("docker_rpminstalled") ||
        it.name.startsWith("docker-rpmbuild") ||
        it.name.startsWith("rpm-deploy")
    )
}
resources.each {
    println "Removing ${it.name}"   
    manager.getResources().remove(it)
}
manager.save()

Aaron.Marasco@BIA-Boeing.com (JIRA)

unread,
Nov 7, 2018, 7:10:03 AM11/7/18
to jenkinsc...@googlegroups.com
Aaron Marasco edited a comment on Improvement JENKINS-38906
Using code from comments above, I have a Jenkins job that runs weekly to remove the ones that start with certain phrases:
{code:java}
 // AV-4738 and stage (" JENKINS-38906 ") {
def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
def resources = manager.getResources().findAll {
    (!it.locked) && (
        it.name.startsWith("docker_rpminstalled") ||
        it.name.startsWith("docker-rpmbuild") ||
        it.name.startsWith("rpm-deploy")
    )
}
  currentBuild.description = "${ resources. size()} locks"
  resources. each {

    println "Removing ${it.name}"   
    manager.getResources().remove(it)
}
manager.save()
} // stage

 {code}

skorhone@gmail.com (JIRA)

unread,
Jan 23, 2019, 11:15:05 AM1/23/19
to jenkinsc...@googlegroups.com

Aaron Marasco You should synchronize access to LocalbleResouceManager, otherwise you might cause race condition. Considering LocakbleResourcesManager relies on synchronization, it should actually be a trivial task to delete lock after it has been released.

skorhone@gmail.com (JIRA)

unread,
Jan 23, 2019, 11:33:03 AM1/23/19
to jenkinsc...@googlegroups.com

We're using this to delete locks after our ansible plays:

@NonCPS
def deleteLocks(lockNames) {
  def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
  synchronized (manager) {
    manager.getResources().removeAll { r -> lockNames.contains(r.name) && !r.locked && !r.reserved }
    manager.save()
  }
}

skorhone@gmail.com (JIRA)

unread,
Jan 24, 2019, 4:18:04 AM1/24/19
to jenkinsc...@googlegroups.com
Sami Korhonen edited a comment on Improvement JENKINS-38906
We're using this to delete locks after our ansible plays:
{code:java}

@NonCPS
def deleteLocks(lockNames) {
  def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
  synchronized (manager) {
    manager.getResources().removeAll { r -> lockNames.contains(r.name) && !r.locked && !r.reserved }
    manager.save()
  }
}

Edit: I had time to study problem further. While this does resolve race condition when deleting item from list, it still isn't sufficient. Current lock allocation algorithm relies that locks are not deleted in any way. I think that's something I can fix. However I think that algorithm needs major rework. Everything related lock management has to be done with atomic operations - and to do so, management must be done in a single class. There might be some scalability issues when allocating hundreds of locks, that could be resolved as well. {code}
 

skorhone@gmail.com (JIRA)

unread,
Jan 24, 2019, 4:18:08 AM1/24/19
to jenkinsc...@googlegroups.com
Sami Korhonen edited a comment on Improvement JENKINS-38906
We're using this to delete locks after our ansible plays:
{code:java}
@NonCPS
def deleteLocks(lockNames) {
  def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
  synchronized (manager) {
    manager.getResources().removeAll { r -> lockNames.contains(r.name) && !r.locked && !r.reserved }
    manager.save()
  }
}
{code}
  Edit: I had time to study problem further. While this does resolve race condition when deleting item from list, it still isn't sufficient. Current lock allocation algorithm relies that locks are not deleted in any way. I think that's something I can fix. However I think that algorithm needs major rework. Everything related lock management has to be done with atomic operations - and to do so, management must be done in a single class. There might be some scalability issues when allocating hundreds of locks, that could be resolved as well. {code}
 

Aaron.Marasco@BIA-Boeing.com (JIRA)

unread,
Jan 24, 2019, 7:55:11 AM1/24/19
to jenkinsc...@googlegroups.com
Aaron Marasco edited a comment on Improvement JENKINS-38906
Using code from comments above, I have a Jenkins job that runs weekly to remove the ones that start with certain phrases . *This may have race conditions* (see later comments) :
{code:java}

stage ("JENKINS-38906") {
  def manager = org.jenkins.plugins.lockableresources.LockableResourcesManager.get()
  def resources = manager.getResources().findAll {
      (!it.locked) && (
          it.name.startsWith("docker_rpminstalled") ||
          it.name.startsWith("docker-rpmbuild") ||
          it.name.startsWith("rpm-deploy")
      )
  }
  currentBuild.description = "${resources.size()} locks"
  resources.each {
      println "Removing ${it.name}"   
      manager.getResources().remove(it)
  }
  manager.save()
} // stage

{code}

Aaron.Marasco@BIA-Boeing.com (JIRA)

unread,
Jan 24, 2019, 7:55:11 AM1/24/19
to jenkinsc...@googlegroups.com

Thanks Sami Korhonen for the heads-up. I don't need to worry about race conditions in my unique situation. However, I'll make a note in case others just see it and copypasta.

 

tobias-jenkins@23.gs (JIRA)

unread,
Oct 12, 2019, 9:08:07 AM10/12/19
to jenkinsc...@googlegroups.com
Tobias Gruetzmacher resolved as Fixed
 

This should be fixed with the ephemeral lock support in release 2.6 - Everthing that is created automatically is now removed automatically.
Change By: Tobias Gruetzmacher
Status: Open Resolved
Assignee: Antonio Muñiz Tobias Gruetzmacher
Resolution: Fixed
Released As: https://github.com/jenkinsci/lockable-resources-plugin/releases/tag/lockable-resources-2.6
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages