Assuming the null value is for the x-auth-token key, the glanceclient http connection doesn't enforce that auth token is set, it just tries to get it if provided and put's it in the header:
And in the nova.image.glance._create_glance_client code, if auth_strategy isn't keystone (which it is by default but I guess you could not use keystone), then the token isn't set on the client connection and if you're not using ssl that's how you could get into this state (since the glance client http connection isn't requiring an auth token):
In this case, are you using auth_strategy=keystone in your nova.conf? I guess it doesn't matter since we still have an exposure here, and we definitely don't test any non-keystone auth strategies in the community CI.
Assuming the null value is for the x-auth-token key, the glanceclient http connection doesn't enforce that auth token is set, it just tries to get it if provided and put's it in the header:
http:// git.openstack. org/cgit/ openstack/ python- glanceclient/ tree/glanceclie nt/common/ http.py? id=0.14. 1#n52
And in the nova.image. glance. _create_ glance_ client code, if auth_strategy isn't keystone (which it is by default but I guess you could not use keystone), then the token isn't set on the client connection and if you're not using ssl that's how you could get into this state (since the glance client http connection isn't requiring an auth token):
http:// git.openstack. org/cgit/ openstack/ nova/tree/ nova/image/ glance. py?id=2014. 2#n150
In this case, are you using auth_strategy= keystone in your nova.conf? I guess it doesn't matter since we still have an exposure here, and we definitely don't test any non-keystone auth strategies in the community CI.