openstack team mailing list archive

[Chmouel Boudjnah <Chmouel.Boudjnah@xxxxxxxxxxxxxxx>]

Hello,

I was actually going to start working on that today as we have review 4893 merged as of last night, basically when you connect with glance to swift :

https://github.com/openstack/glance/blob/master/glance/store/swift.py#L306

You need to have an option in glance to connect to a auth 2.0 server like :

swift_auth_version = 2
 
and pass auth_version=2 to swift_client.Connection :

https://github.com/openstack/swift/blob/master/swift/common/client.py#L796

Which should be able to get the images for that username/key stored in keystone.

If you would like to have a go on it please feel free as I don't know very glance code-base (but there is always a start :))

Chmouel.

PS: Ccing the public mailing-list as I think it would be more useful to have those discussions in public.

________________________________________
From: Haefliger, Juerg [Juerg.Haefliger@xxxxxx]
Sent: 16 March 2012 12:11
To: Pipes, Jay; Chmouel Boudjnah
Subject: RE: Re: Fwd: RE: Keystone auth issues with Swift

Hi guys,

Thanks for the info.  I still have some questions though.

I applied https://review.openstack.org/#change,4893 to my local branch. When you say 'Glance doesn't speak 2.0' which part of Glance are you referring to? The CLI or some other component? Where do I have to make modifications to get this working? Glance only or some middleware in keystone as well?

Thanks
...Juerg


> -----Original Message-----
> From: Pipes, Jay
> Sent: Thursday, March 15, 2012 8:54 PM
> To: Haefliger, Juerg
> Subject: Fwd: Re: Fwd: RE: Keystone auth issues with Swift
>
> Hey again!
>
> See below an explanation from Chmouel as to what may be happening...
>
> All the best,
> jay
>
> -------- Original Message --------
> Subject:      Re: Fwd: RE: Keystone auth issues with Swift
> Date:         Tue, 13 Mar 2012 14:09:32 -0000
> From:         Chmouel Boudjnah <chmouel@xxxxxxxxxxx>
> To:   Pipes, Jay <jay.pipes@xxxxxx>
>
>
>
> Hello Jay,
>
> This is because Glance doesn't 'speak' Auth 2.0 when using
> swift.client, see this bug :
>
> https://bugs.launchpad.net/glance/+bug/944946
>
> Would love to make this works but this review has been sitting :
>
> https://review.openstack.org/#change,4893
>
> The way it should work, should be[1]  :
>
> Glance => swift.client (2.0 ''mode'') => Keystone (get us a token) =>
> Swift => SwiftAuth => Validate token => Access
>
> There is probably going to have some caching around this to avoid some
> round trip.
>
> Cheers,
> Chmouel.
>
> [1] It may look confusing let me know if you want some kind of diagram.
>
> On 03/13/2012 01:58 PM, Pipes, Jay wrote:
> > Hi Chmouel, hoping you might be able to help me out. I've got an HPer
> > who is trying to get Diablo Glance + Swift working properly with
> Keystone.
> >
> > Basically, it looks like the Glance auth_token middleware is
> correctly
> > handling Keystone authentication and using the swift CLI tool works
> > fine with Keystone auth.
> >
> > However, adding an image through the glance client using a Swift
> > backend is failing (see below in original email).
> >
> > I'm wondering if there's something obvious that I'm missing? AFAIK,
> > the Glance Swift backend driver simply calls the swift client,
> passing
> > in the user/key that is stored in the Glance config
> > store_swift_auth_user/key values. The token *should* be created by
> the
> > swift_auth middleware when it sees an HTTP request with X-Auth-User
> > and X-Auth-Key headers (that the Glance Swift backend driver
> supplies), right?
> >
> > Thanks in advance for any insight you might have!
> > -jay
> >
> > -------- Original Message --------
> > Subject: RE: Keystone auth issues with Swift
> > Date: Tue, 13 Mar 2012 09:09:37 -0000
> > From: Haefliger, Juerg<Juerg.Haefliger@xxxxxx
> > <mailto:Juerg.Haefliger@xxxxxx>>
> > To: Pipes, Jay<jay.pipes@xxxxxx  <mailto:jay.pipes@xxxxxx>>
> >
> > Hi Jay,
> >
> > Thanks for the suggestion but it didn't help :-(
> >
> > Doing some tracing, I can see the following sequence (which is
> > identical with or without the -A option) when trying to add an image
> > through
> > glance:
> >
> > glance-api: auth_token: env contains'HTTP_X_AUTH_TOKEN'
> > glance-api: glance_auth_token: req.headers contains'X-Auth-Token'
> > glance-registry: auth_token: env contains'HTTP_X_AUTH_TOKEN'
> > glance-registry: glance_auth_token: req.headers contains'X-Auth-
> Token'
> > swift-proxy-server: swift_auth: env does not
> contain'HTTP_X_AUTH_TOKEN'
> >
> > glance_token_auth pulls the X-Auth-Token from the request header and
> > creates a context that contains it. Somehow that context doesn't make
> > it over to swift_auth. Am I missing a context filter in one of the
> > config files or something? I don't really understand paste.deploy and
> > the filters so how is the env for swift_auth created?
> >
> > Thanks
> > ...Juerg
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Pipes, Jay
> >> Sent: Monday, March 12, 2012 7:00 PM
> >> To: Haefliger, Juerg
> >> Subject: Re: Keystone auth issues with Swift
> >>
> >> Hi!
> >>
> >> Yeah, Keystone middleware is a mess IMHO (for all projects, not just
> >> Glance and Swift).
> >>
> >> If you try adding a -A<SERVICE_TOKEN>  option to your glance add
> >> command, see if it works.
> >>
> >> If it does, that means that the glance_auth_token middleware in
> >> Keystone isn't properly adding the X-Auth-Token header
> >>
> >> Lemme know,
> >> -jay
> >>
> >> On 03/12/2012 06:20 AM, Haefliger, Juerg wrote:
> >>> Hi Jay,
> >>>
> >>> I was wondering if you can lend a hand. For the fun of it, I've
> >>> installed keystone, glance and swift (Diablo) on a local machine.
> > All
> >>> services are configured to the point that I can run, for example,
> >>> 'glance index'  and'swift .. stat'  commands successfully. Auth
> with
> >>> keystone seems to work in these cases. But when I try to upload an
> >>> image through glance I get:
> >>>
> >>> root@jabba:~# glance add name=testing<   testing Failed to add
> image.
> >>> Got error:
> >>> 400 Bad Request
> >>>
> >>> The server could not comply with the request since it is either
> >>> malformed or otherwise incorrect.
> >>>
> >>>    Error uploading image: (ClientException): Auth GET failed:
> >>> http://127.0.0.1:8080/auth/v1.0  401 Unauthorized
> >>> Note: Your image metadata may still be in the registry, but the
> >>> image's status will likely be'killed'.
> >>>
> >>>
> >>> What I've found so far is that keystone/middleware/swift_auth.py is
> >>> trying to extract the HTTP_X_AUTH_TOKEN from the env which is not
> >> there.
> >>> Instead, there are HTTP_X_AUTH_USER and HTTP_X_AUTH_KEY in the env.
> >>>
> >>> Here's the relevant code from swift_auth.py:
> >>>
> >>>           self.log.info  <http://self.log.info>('Keystone
> middleware called')
> >>>           self.log.info  <http://self.log.info>(env)
> >>>           token = self._get_claims(env)
> >>>           self.log.info  <http://self.log.info>('token: %s', token)
> >>>           if token:
> >>>               identity = self._validate_claims(token)
> >>>               if identity:
> >>>                   self.log.info  <http://self.log.info>('request
> >>> authenticated: %r',
> > identity)
> >>>                   return
> >>> self.perform_authenticated_request(identity,
> >>> env,
> >>>
> >>> start_response)
> >>>               else:
> >>>                   self.log.info  <http://self.log.info>('anonymous
> request')
> >>>                   return self.unauthorized_request(env,
> >> start_response)
> >>>           self.log.info  <http://self.log.info>('no auth token in
> >>> request headers')
> >>>
> >>>
> >>> And the log looks like the following:
> >>>
> >>> Mar 12 11:03:14 jabba proxy-server Keystone middleware called Mar
> 12
> >>> 11:03:14 jabba proxy-server {'SCRIPT_NAME':'',
> >>> 'HTTP_X_AUTH_KEY':'glance','REQUEST_METHOD':'GET','PATH_INFO':
> >>> '/auth/v1.0','SERVER_PROTOCOL':'HTTP/1.0','wsgi.url_scheme':
> >>> 'http',
> >>> 'eventlet.posthooks': [],'SERVER_NAME':'127.0.0.1','REMOTE_ADDR':
> >>> '127.0.0.1','eventlet.input':<eventlet.wsgi.Input object at
> >>> 0x2ff7290>,'HTTP_X_AUTH_USER':'glance:glance','SERVER_PORT':
> >>> 0x2ff7290>'8080',
> >>> 'wsgi.input':<eventlet.wsgi.Input object at 0x2ff7290>,'HTTP_HOST':
> >>> '127.0.0.1:8080
> >>>
> <http://127.0.0.1:8080>','swift.cache':<swift.common.memcached.Memca
> >>> cheRing object at 0x2fcd5d0>,'wsgi.multithread':
> >>> True,'wsgi.version': (1, 0),
> >>> 'GATEWAY_INTERFACE':'CGI/1.1','wsgi.run_once': False,
> >> 'wsgi.errors':
> >>> <swift.common.utils.LoggerFileObject object at 0x2f54890>,
> >>> 'wsgi.multiprocess': False,'CONTENT_TYPE': None,
> >>> 'HTTP_ACCEPT_ENCODING':'identity'}
> >>> Mar 12 11:03:14 jabba proxy-server token: None Mar 12 11:03:14
> jabba
> >>> proxy-server no auth token in request headers
> >>>
> >>>
> >>> Any ideas what's going wrong and where?
> >>>
> >>> Thanks
> >>> ...Juerg
> >>>