<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 02/12/2014 05:55 PM, Sean Dague
      wrote:<br>
    </div>
    <blockquote cite="mid:52FBFBD1.2060403@dague.net" type="cite">
      <pre wrap="">On 02/12/2014 05:08 PM, Boris Pavlovic wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi all, 

It goes without saying words that actually tempest[1] is only one public
known tool that could fully verify deployments and ensure dthat they work.

In Rally[2] we would like to use it as a cloud verifier (before
benchmarking it is actually very useful;) to ensure that cloud work). We
are going to build on top of tempest pretty interface and aliases &
support of working with different clouds. E.g.: 

rally use deployment <uuid> # use some deployment that is registered in
Rally
rally verify nova # Run only nova tests against `in-use` deployment 
rally verify small/big/full # set of tests
rally verify list # List all verification results for this deployment
rally verify show <id> # Show detailed information
# Okay we found that something failed, fixed it in cloud, restart
service and we would like you to run only failed tests
rally verify latest_failed # do it in one simple command

These commands should be very smart, generate proper tempest.conf for
specific cloud, prepare cloud for tempest testing, store somewhere
results and so on and so on. So at the end we will have very simple way
to work with tempest. 

We added first patch that adds base functionality to Rally [3]: 
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/70131/">https://review.openstack.org/#/c/70131/</a>

At QA meeting I discussed it with David Kranz, as a result we agree that 
part of this functionality (tempest.conf generator & cloud prepare),
should be implemented inside tempest.

Current situation is not super cool because, there are at least 4
projects where we are generating in different way tempest.conf: 
1) DevStack
2) Fuel CI
3) Rally
4) Tempest (currently broken)


To put it in a nutshell, it's clear that we should make only 1
tempest.conf generator [4], that will cover all cases, and will be
enough simple to be used in all other projects. 
</pre>
      </blockquote>
      <pre wrap="">
So in the past the issue was we could never get anyone to agree on one.
For instance, devstack makes some really fine grained decisions, and the
RDO team showed up with a very different answer file approach, which
wouldn't work for devstack (it had the wrong level of knob changing).

And if the end of the day you replace build a tempest config generator,
which takes 200 options, I'm not entirely sure how that was better than
just setting those 200 options directly.

So while happy to consider options here, realize that there is a reason
this has been punted before.

        -Sean</pre>
    </blockquote>
    I have thought about this and think we can do better. I will present
    a spec when I get a chance if no one else does. I would leave
    devstack out<br>
    of it, at least for now. In general it would be good to decouple
    tempest from devstack a little more, especially as it gains wider
    use in rally, refstack, etc. For example, there are default paths
    and stuff in tempest.conf.sample that refer to files that are only
    put there by devstack.<br>
    <br>
     -David<br>
    <blockquote cite="mid:52FBFBD1.2060403@dague.net" type="cite">
      <pre wrap="">

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>