Fix token caching for multi-cluster multi-namespace environments #261
Conversation
|
@jglick this has been open for more a year, and the plugin is basically broken and unusable. I am not 100% sure but I think it will affect in-cluster JWT auth too for when jenkins is in k8s. Will this ever be merged? How is anyone using it, does everybody using static tokens and are happy? |
|
I am not a maintainer of this plugin (and do not even know much about it) so I am not sure why you are mentioning me. |
|
@jglick sorry, I looked at the last commit author and since you are everywhere I just assumed you might be a right person to tag. cc @jetersen please see above. This is a critical issue, and it renders this plugin unusable for anyone having more than one vault cluster in the environment. I have been running a custom build with my fix in production large scale environment for a year now and there are no issues. |
| } | ||
| } | ||
|
|
||
| private ConcurrentMap<CacheKey, TokenHolder> cache = new ConcurrentHashMap<>(); |
There was a problem hiding this comment.
Instead of ConcurrentMap we might as well pull in caffeine.
<dependency>
<groupId>io.jenkins.plugins</groupId>
<artifactId>caffeine-api</artifactId>
</dependency>
See #260.
New implementation uses caching criteria to differentiate tokens for different environments. So far I only came up with two possible attributes - server address and a namespace, but I have created
CacheKeyto allow for easy extension later on if more colliding attributes will be discovered. I have also addedtransientwhere I think it applies since I do not think we want to cache be ever written to the disk. I also added a little thread safety, although I am not sure if it is necessary (and I did not observe any issues with it so far) but it felt like it is.