OK, so the source of this issue is actually in Keystone. The glance_auth_token middleware is creating the RequestContext that Glance uses when querying for the caller's tenant. The code uses the value of the X_TENANT header to populate the tenant supplied to the RequestContext's constructor, which is what Glance ends up storing in the registry as the image owner_id.
So... the solution, I think, is to patch the glance_auth_token middleware in Keystone to use the value of the X_TENANT_ID header, not X_TENANT, and write some sort of data migration script to address the problem of stored owner_id values being name and not ID of tenant.
From Jay on the ML:
OK, so the source of this issue is actually in Keystone. The glance_auth_token middleware is creating the RequestContext that Glance uses when querying for the caller's tenant. The code uses the value of the X_TENANT header to populate the tenant supplied to the RequestContext's constructor, which is what Glance ends up storing in the registry as the image owner_id.
So... the solution, I think, is to patch the glance_auth_token middleware in Keystone to use the value of the X_TENANT_ID header, not X_TENANT, and write some sort of data migration script to address the problem of stored owner_id values being name and not ID of tenant.