<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 04/16/2014 11:48 AM, Jaume Devesa
      wrote:<br>
    </div>
    <blockquote
cite="mid:CABvUA7=ewb-uFGDnP7oorCpjaxbG3T2gdNxnNjurHeGss_wc4w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:tahoma,sans-serif">Hi

          Sean,</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">
          for what I understood, we will need a new feature flag for
          each new feature, and a feature flag (default to false) for
          each deprecated one. My concern is: since the goal is make
          tempest a confident tool to test any installation and not and
          'tempest.conf' will not be auto-generated from any tool as
          devstack does, wouldn't be too hard to prepare a tempest.conf
          file with so many feature flags to enable and disable?</div>
      </div>
    </blockquote>
    If we go down this route, and I think we should, we probably need to
    accept that it will be hard for users to manually configure
    tempest.conf. Tempest configuration would have to be done by
    whatever installation technology was used, as devstack does, or by
    auto-discovery. That implies that the presence of new features
    should be discoverable through the api which is a good idea anyway.
    Of course some one could configure it manually but IMO that is not
    desirable even with where we are now.<br>
    <blockquote
cite="mid:CABvUA7=ewb-uFGDnP7oorCpjaxbG3T2gdNxnNjurHeGss_wc4w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">Maybe

          I am simplifying too much, but wouldn't be enough with a pair
          of functions decorators like</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">@new</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">@deprecated</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">Then,

          in tempest.conf it could be a flag to say which OpenStack
          installation are you testing:</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">installation

          = [icehouse|juno]</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">
          <br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">if

          you choose Juno, tests with @new decorator will be executed
          and tests with @deprecated will be skipped.</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">
          If you choose Icehouse, tests with @new decorator will be
          skipped, and tests with @deprecated will be executed</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">
          I am missing some obvious case that make this approach a
          nonsense?</div>
      </div>
    </blockquote>
    There are two problems with this. First, some folks are chasing
    master for their deployments and some do not deploy all the features
    that are set up by devstack. In both cases, it is not possible to
    identify what can be tested with a simple name that corresponds to a
    stable release. Second, what happens when we move on to K? The
    meaning of "new" would have to change while retaining its old
    meaning as well which won't work. I think Sean spelled out the
    important scenarios.<br>
    <br>
     -David<br>
    <blockquote
cite="mid:CABvUA7=ewb-uFGDnP7oorCpjaxbG3T2gdNxnNjurHeGss_wc4w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">Regards,</div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">jaume</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 14 April 2014 15:21, Sean Dague <span
            dir="ltr"><<a moz-do-not-send="true"
              href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">As we're
            coming up on the stable/icehouse release the QA team is
            looking<br>
            pretty positive at no longer branching Tempest. The QA Spec
            draft for<br>
            this is here -<br>
            <a moz-do-not-send="true"
href="http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html"
              target="_blank">http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html</a><br>
            and hopefully address a lot of the questions we've seen so
            far.<br>
            <br>
            Additional comments are welcome on the review -<br>
            <a moz-do-not-send="true"
              href="https://review.openstack.org/#/c/86577/"
              target="_blank">https://review.openstack.org/#/c/86577/</a><br>
            or as responses on this ML thread.<br>
            <span class="HOEnZb"><font color="#888888"><br>
                        -Sean<br>
                <br>
                --<br>
                Sean Dague<br>
                Samsung Research America<br>
                <a moz-do-not-send="true" href="mailto:sean@dague.net">sean@dague.net</a>
                / <a moz-do-not-send="true"
                  href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
                <a moz-do-not-send="true" href="http://dague.net"
                  target="_blank">http://dague.net</a><br>
                <br>
              </font></span><br>
            _______________________________________________<br>
            OpenStack-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
              target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <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>