Fake Keystone server for test purposes

Registered by Erno Kuvaja

As keystone is only supported auth method for glance we should be doing our functional tests against keystone pipeline as well.

This would make testing easier for example testing glance api v2 with registry as v2 registry client does not pass all the headers (like tenant-id) to registry server.

Idea behind fake keystone server is to provide light process that can be spun up and it would handle small subset of Keystone API. Mainly auth token verification and username + password authentication. The fake keystone server would have pre determined set of tokens and users that will be imported during the start of the server and it will return failure respose to any other user+password/token thown at it. This will also make possible to change the default pipeline from noauth to keystone without breaking all tests (during the functional tests the services will be spun up with default config as well as with the config specified in the test cases).

Blueprint information

Erno Kuvaja
Needs approval
Erno Kuvaja
Series goal:
Milestone target:
Started by
Erno Kuvaja

Related branches



Hi Erno,

This blueprint was accidentally untargeted during the development of some scripts for managing launchpad and the glance-specs repo.

I'm a little concerned about how processes add slowness to our testing cycle. The current effort (stalled out) has been to move functional tests into "integration" tests where external processes are not used. That being said, I think keeping some functional tests around but minimizing their number and assertion depth is a fine approach, and using a fake keystone for such tests would be fine.

How do you feel about slowness in testing and adapting your proposal to the test speed effort I have described?

Also, can we take this discussion outside of launchpad? maybe the next team meeting or if you want to make a glance-specs entry. Whiteboard changes are really hard to track.


Hi Mark,

I'll put topic in for this weeks meeting.

If I have read the situation correctly, we can't even change glance defaulting to keystone because it breaks our current functional tests. I do understand and very much agree with the concerns around the slowness of the tests, but I think the consensus has been so far that we rather want to wait and run lots of tests than not test the code.

The bug #1308413 which originally triggered me to look into this option shows that we miss some scenarios by solely relying on unit tests.

Let's continue this discussion at Thu meeting.



Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.