<p dir="ltr">Monty, you missed a couple of elements of the original program definition - the mappings from the tempest based "scorecard" to specific versions of the API docs, and the availability of the tested and verified endpoints to "tools ecosystem" developers.</p>

<p dir="ltr">Also, I believe the definition of "compliance" rests with the Board and not the TC, despite some debate as to whether we're capable of handling it.</p>
<p dir="ltr">And I'll arm-wrestle you for the PTL slot ;)</p>
<p dir="ltr">PS - for the purposes of FITS, the "candidate cloud" can be either a public cloud, or a test environment for private cloud software.</p>
<div class="gmail_quote">On Jul 9, 2013 8:03 AM, "Monty Taylor" <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
I'd like to propose an official program to the TC - refstack, a program<br>
for verifying interoperability between implementations via FITS testing.<br>
<br>
Official Title: OpenStack Interoperability<br>
Initial PTL: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
Mission Statement:<br>
  Develop and maintain FITS testing and interoperability reporting for<br>
  OpenStack deployments and distributions.<br>
<br>
For a little background, the specific incarnation of the idea for this<br>
came up at the last in-person Foundation Board meeting, and I think it's<br>
a good idea. Also, it turns out there’s a reference in the logo<br>
guidelines stating that any FITS defined by the TC and made available by<br>
OpenStack needs to be passed before the logos can be used for a product.<br>
<br>
Follow on discussions were held at the summit, and a general approach of<br>
basing the testing of clouds on tempest was agreed to. The general idea<br>
is that for any given cloud, refstack will run tempest against the cloud<br>
in a standard configuration (not re-configuring tempest on a per-cloud<br>
basis) This will result in a set of passing and failing tests. That<br>
output then needs to be processed and presented in a way that it can be<br>
the basis of determining which elements are compliant and not. The<br>
ultimate decisions around which elements would be 'required' to be a<br>
compliant deployment would come back to the TC, and how that compliance<br>
translates in to trademark usage goes back to the board. But it's the<br>
job of refstack to be able to test the candidate cloud and report on its<br>
actual capabilities.<br>
<br>
In conjunction with this a 'reference' deployment config is needed, so<br>
that we can validate that our test is passable. At the moment I would<br>
expect this to be the de-facto standard which is devstack, but that's<br>
ultimately a happenstance and opportunistic config, and over time the<br>
refstack program would be involved in helping to define a deployment<br>
configuration or configurations that we as a community feel should<br>
reasonably be expected to pass our own FITS testing.<br>
<br>
Expected outputs:<br>
 - A service for submission of cloud endpoint information for testing<br>
 - Processing of tempest output into a service compliance report<br>
 - One or more deployment configurations that can, themselves, pass the<br>
testing 100%<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
</blockquote></div>