To answer my own question, it looks like calling
Jenkins.instance.trimLabels() after doing all the manipulation works.
This is a private method, but it is callable from groovy. Alternatively,
it looks like calling Jenkins.instance.setNodes(Jenkins.instance.nodes)
would also trigger this. I think I'm going to go with
def h = Jenkins.instance
// manipulate labels
synchronized(h) {
h.setNodes(h.nodes)
}
On 12/30/2015 02:07 PM, Jay Berkenbilt wrote:
> I have some groovy code that, under certain conditions, changes the
> labels on nodes, and I've been having a hard time figuring out exactly
> how to do it in a way that takes effect right away.
>
> I can do something like
>
> def slave = Hudson.instance.getSlave("slave-name")
> slave.labelString = "new labels here"
>
> This works "eventually". The slave shows the new labels immediately, but
> for some period of time, Jenkins will continue to assign jobs based on
> the old labels.
>
> Something more like this
>
> def h = Hudson.instance
> def slave = h.getSlave("slave-name")
> h.removeNode(slave)
> h.labelString = "new labels here"
> h.addNode(slave)
>
> works immediately but has the disadvantage of temporarily removing the
> slave, which causes various race conditions including possibly aborting
> a job that jumped onto the slave right as we were about to change the
> label. Reading the source code, I can see that stuff has to be updated
> in Jenkins' internal idea of which slaves have which labels, that this
> happens periodically for various reasons, and that adding and removing
> the node triggers it at least for the affected node, but I can't find an
> API to force it to happen for all nodes or for a specific node when I
> want it to happen. Calling slave.save() doesn't seem to affect this. I
> am trying to dig through the code path that is traversed when a slave is
> reconfigured, but I'm hoping to find some simpler way.
>
> For what it's worth, my use case is that we have dynamic slaves, and we
> remove slaves that have been idle for a certain amount of time. The
> problem is that sometimes a job may jump onto the slave as it's being
> removed. This actually happens regularly. I want to work around the race
> condition by first removing the labels that allow jobs to go there and
> then rechecking whether it's idle, but I can't find a way to do that
> that doesn't have an equally bad race condition.
>
> --Jay
>
--
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/568AC5BB.2090807%40ql.org.
For more options, visit https://groups.google.com/d/optout.
