[openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests
Minying Lu
mylu at bu.edu
Tue Apr 5 14:38:13 UTC 2016
Thank you all for your awesome feedbacks!
On Sun, Apr 3, 2016 at 9:07 PM, Jamie Lennox <jamielennox at gmail.com> wrote:
>
>
> On 2 April 2016 at 09:21, Rodrigo Duarte <rodrigodsousa at gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish <mtreinish at kortar.org>
>> wrote:
>>
>>> 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
>> https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests
>>
>>
>
> Again though, the problem is not where the tests live but where we run
> them. To practically run these tests we need to either add K2K testing
> support to devstack (not sure this is appropriate) or come up with a new
> test environment that deploys 2 keystones and federation support that we
> can CI against in the gate. This is doable but i think something we need
> support with from infra before worrying about tempest.
>
>
>
>
>>> 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
>> http://rodrigods.com
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160405/ade8bff2/attachment.html>
More information about the OpenStack-dev
mailing list