<div dir="ltr">Thank you all for your awesome feedbacks! <br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 3, 2016 at 9:07 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@gmail.com" target="_blank">jamielennox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 2 April 2016 at 09:21, Rodrigo Duarte <span dir="ltr"><<a href="mailto:rodrigodsousa@gmail.com" target="_blank">rodrigodsousa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote:<br>
> Hi all,<br>
><br>
> I'm working on resource federation at the Massachusetts Open Cloud. We want<br>
> to implement functional test on the k2k federation, which requires<br>
> authentication with both a local keystone and a remote keystone (in a<br>
> different cloud installation). It also requires a K2K/SAML assertion<br>
> exchange with the local and remote keystones. These functions are not<br>
> implemented in the current tempest.lib.service library, so I'm adding code<br>
> to the service library.<br>
><br>
> My question is, is it possible to adapt keystoneauth python clients? Or do<br>
> you prefer implementing it with http requests.<br>
<br>
</span>So tempest's clients have to be completely independent. That's part of tempest's<br>
design points about testing APIs, not client implementations. If you need to add<br>
additional functionality to the tempest clients that's fine, but pulling in<br>
keystoneauth isn't really an option.<br></blockquote></span><div><br>++<br> </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
><br>
> And since this test requires a lot of environment set up including: 2<br>
> separate cloud installations, shibboleth, creating mapping and protocols on<br>
> remote cloud, etc. Would it be within the scope of tempest's mission?<br>
<br>
</span>From the tempest perspective it expects the environment to be setup and already<br>
exist by the time you run the test. If it's a valid use of the API, which I'd<br>
say this is and an important one too, then I feel it's fair game to have tests<br>
for this live in tempest. We'll just have to make the configuration options<br>
around how tempest will do this very explicit to make sure the necessary<br>
environment exists before the tests are executed.<br></blockquote></span><div><br><div>Another option is to add those tests to keystone itself (if you are
 not including tests that triggers other components APIs). See 
<a href="https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests" target="_blank">https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests</a><br></div> </div></div></div></div></blockquote></div></div><div><br>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. <br><br>  </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The fly in the ointment for this case will be CI though. For tests to live in<br>
tempest they need to be verified by a CI system before they can land. So to<br>
land the additional testing in tempest you'll have to also ensure there is a<br>
CI job setup in infra to configure the necessary environment. While I think<br>
this is a good thing to have in the long run, it's not necessarily a small<br>
undertaking.<br></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Matt Treinish<br>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#666666">Rodrigo Duarte Sousa<br></font></div><div><font color="#666666">Senior Quality Engineer @ Red Hat<br></font></div><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">MSc</span><span style="color:rgb(102,102,102)"></span><span style="color:rgb(102,102,102)"> in Computer Science</span><br><font color="#3333ff"><a href="http://rodrigods.com" target="_blank">http://<font color="#3333ff">rodrigods.com</font></a></font></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>