【踩坑】OpenStack4j使用过程中关于OSClientSession被更改的问题记录
OpenStack4j是一个OpenStack的Java SDK。
问题描述
在同一个代码处理线程中，首先获取了 projectA 的 OSClient 对象 OSClientA，然后又获取了 projectB 的 OSClient 对象 OSClientB。
后续在用 OSClientA 去调用某个 service（比如 BlockVolumeService）去创建资源（比如 volume）的时候，期望创建在 projectA 下面，结果创建的资源却在 projectB 下面。
查找原因
经过跟踪 OpenStack4j 中获取 OSClient 和 调用具体 service 的相关源码后，发现问题，在于 OSClientSession 类中使用 ThreadLocal 变量 sessions 将获取的 OSClient 存下来。
后续在创建资源的时候，使用从 sessions 中取出的OSClient ，调用 OpenStack 的 API 接口。
关键在于，第二次获取 OSClientB 的时候，会将 sessions 中存的 OSClient 更新，将原先的 OSClientA 给替换为 OSClientB。
也就造成了，尽管是用 OSClientA 去创建资源，但是实际使用的 OSClient 已经被改了，也就是是用 OSClientB 的相关参数去创建的。
源码分析
获取 OSClient 的代码在 OSAuthenticator#authenticateV3(默认使用的是v3版本)。
......
private static OSClientV3 authenticateV3(KeystoneAuth auth, SessionInfo info, Config config) {
if (auth.getType().equals(Type.TOKENLESS)){
......
}
# 调用 OpenStack keystone 的认证接口
HttpRequest<KeystoneToken> request = HttpRequest.builder(KeystoneToken.class)
.header(ClientConstants.HEADER_OS4J_AUTH, TOKEN_INDICATOR).endpoint(info.endpoint)
.method(HttpMethod.POST).path("/auth/tokens").config(config).entity(auth).build();
HttpResponse response = HttpExecutor.create().execute(request);
if (response.getStatus() >= 400) {
try {
throw mapException(response.getStatusMessage(), response.getStatus());
} finally {
HttpEntityHandler.closeQuietly(response);
}
}
KeystoneToken token = response.getEntity(KeystoneToken.class);
token.setId(response.header(ClientConstants.HEADER_X_SUBJECT_TOKEN));
.......
String reqId = response.header(ClientConstants.X_OPENSTACK_REQUEST_ID);
# info.reLinkToExistingSession 在前面的调用过程中传参是 false。
if (!info.reLinkToExistingSession) {
# 创建了一个 OSClient，OSClientSessionV3 是 v3 版本的实现类
OSClientSessionV3 v3 = OSClientSessionV3.createSession(token, info.perspective, info.provider, config);
v3.reqId = reqId;
return v3;
}
OSClientSessionV3 current = (OSClientSessionV3) OSClientSessionV3.getCurrent();
current.token = token;
current.reqId = reqId;
return current;
}
OSClientSessionV3#createSession，也是关键的地方。
public static OSClientSessionV3 createSession(Token token, Facing perspective, CloudProvider provider, Config config) {
return new OSClientSessionV3(token, token.getEndpoint(), perspective, provider, config);
}
......
public static class OSClientSessionV3 extends OSClientSession<OSClientSessionV3, OSClientV3> implements OSClientV3 {
Token token;
protected String reqId;
private OSClientSessionV3(Token token, String endpoint, Facing perspective, CloudProvider provider, Config config) {
this.token = token;
this.config = config;
this.perspective = perspective;
this.provider = provider;
# 重点在这里
sessions.set(this);
}
......
接着看一下 sessions 这个变量
public abstract class OSClientSession<R, T extends OSClient<T>> implements EndpointTokenProvider {
private static final Logger LOG = LoggerFactory.getLogger(OSClientSession.class);
# 可以看到 sessions 是一个 ThreadLocal 变量，而每一次创建新的 OSClientSession，会调用 set 方法，
# 覆盖之前的 OSClientSession。
@SuppressWarnings("rawtypes")
private static final ThreadLocal<OSClientSession> sessions = new ThreadLocal<OSClientSession>();
Config config;
Facing perspective;
String region;
Set<ServiceType> supports;
CloudProvider provider;
Map<String, ? extends Object> headers;
EndpointURLResolver fallbackEndpointUrlResolver = new DefaultEndpointURLResolver();
由以上的源码知道，每次获取 OSClient（即创建新的OSClientSessionV3）的时候，会在 sessions 中覆盖之前的。
看完获取的过程，再去确认一下调用具体 service 创建资源的时候，是否是从 sessions 中取出的 OSClient。
无论哪个 service 中方法，最终都是使用统一的 http 调用方法 HttpExecutorServiceImpl#invokeRequest。
......
private <R> HttpResponse invokeRequest(HttpCommand<R> command) throws Exception {
Response response = command.execute();
if (command.getRetries() == 0 && response.getStatus() == 401 && !command.getRequest().getHeaders().containsKey(ClientConstants.HEADER_OS4J_AUTH))
{
# 重点看这个方法的实现，同样是 OSAuthenticator 类中的
OSAuthenticator.reAuthenticate();
command.getRequest().getHeaders().put(ClientConstants.HEADER_X_AUTH_TOKEN, OSClientSession.getCurrent().getTokenId());
return invokeRequest(command.incrementRetriesAndReturn());
}
return HttpResponseImpl.wrap(response);
}
OSAuthenticator.reAuthenticate()
/**
* Re-authenticates/renews the token for the current Session
*/
@SuppressWarnings("rawtypes")
public static void reAuthenticate() {
LOG.debug("Re-Authenticating session due to expired Token or invalid response");
OSClientSession session = OSClientSession.getCurrent();
switch (session.getAuthVersion()) {
case V2:
KeystoneAccess access = ((OSClientSessionV2) session).getAccess().unwrap();
SessionInfo info = new SessionInfo(access.getEndpoint(), session.getPerspective(), true,
session.getProvider());
Auth auth = (Auth) ((access.isCredentialType()) ? access.getCredentials() : access.getTokenAuth());
authenticateV2((org.openstack4j.openstack.identity.v2.domain.Auth) auth, info, session.getConfig());
break;
case V3:
default:
Token token = ((OSClientSessionV3) session).getToken();
info = new SessionInfo(token.getEndpoint(), session.getPerspective(), true, session.getProvider());
# 从 sessions 中获取 OSClientSessionV3 之后，同样调用 authenticateV3 认证
authenticateV3((KeystoneAuth) token.getCredentials(), info, session.getConfig());
break;
}
}
虽然和获取 OSClient 的时候一样，都调用了OSAuthenticator#authenticateV3。但是需要注意，上面说到 info.reLinkToExistingSession 这个参数在获取的时候传参为 false，而这里的传参是 true。
代表它会重新连接已经存在的 Session。
......
private static OSClientV3 authenticateV3(KeystoneAuth auth, SessionInfo info, Config config) {
......
# info.reLinkToExistingSession 在这里传参是 true，所以不会再创建新的。
if (!info.reLinkToExistingSession) {
# 创建了一个 OSClient，OSClientSessionV3 是 v3 版本的实现类
OSClientSessionV3 v3 = OSClientSessionV3.createSession(token, info.perspective, info.provider, config);
v3.reqId = reqId;
return v3;
}
# 取出当前的 OSClient，直接返回。
OSClientSessionV3 current = (OSClientSessionV3) OSClientSessionV3.getCurrent();
current.token = token;
current.reqId = reqId;
return current;
}
结论
从上面的源码分析结合我的问题可以得知，在 OSAuthenticator.reAuthenticate() 取出的当前的 OSClient 是 OSClientB，而不是 OSClientA，所以导致了资源创建在了 projectB 下面。
分享一下自己踩坑的问题分析，希望大家都可以及时发现并避免因此出现意想不到的 Bug。
