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 [email protected].
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.
