[openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

Rodrigo Duarte rodrigodsousa at gmail.com
Fri Apr 1 22:21:42 UTC 2016

On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish <mtreinish at kortar.org>

> On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote:
> > Hi all,
> >
> > I'm working on resource federation at the Massachusetts Open Cloud. We
> want
> > to implement functional test on the k2k federation, which requires
> > authentication with both a local keystone and a remote keystone (in a
> > different cloud installation). It also requires a K2K/SAML assertion
> > exchange with the local and remote keystones. These functions are not
> > implemented in the current tempest.lib.service library, so I'm adding
> code
> > to the service library.
> >
> > My question is, is it possible to adapt keystoneauth python clients? Or
> do
> > you prefer implementing it with http requests.
> So tempest's clients have to be completely independent. That's part of
> tempest's
> design points about testing APIs, not client implementations. If you need
> to add
> additional functionality to the tempest clients that's fine, but pulling in
> keystoneauth isn't really an option.


> >
> > And since this test requires a lot of environment set up including: 2
> > separate cloud installations, shibboleth, creating mapping and protocols
> on
> > remote cloud, etc. Would it be within the scope of tempest's mission?
> From the tempest perspective it expects the environment to be setup and
> already
> exist by the time you run the test. If it's a valid use of the API, which
> I'd
> say this is and an important one too, then I feel it's fair game to have
> tests
> for this live in tempest. We'll just have to make the configuration options
> around how tempest will do this very explicit to make sure the necessary
> environment exists before the tests are executed.

Another option is to add those tests to keystone itself (if you are not
including tests that triggers other components APIs). See

> The fly in the ointment for this case will be CI though. For tests to live
> in
> tempest they need to be verified by a CI system before they can land. So to
> land the additional testing in tempest you'll have to also ensure there is
> a
> CI job setup in infra to configure the necessary environment. While I think
> this is a good thing to have in the long run, it's not necessarily a small
> undertaking.

> -Matt Treinish
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160401/b226a780/attachment.html>

More information about the OpenStack-dev mailing list