<div dir="ltr">Joshua, <div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Makes sense, perhaps all the test (and/or test-like) frameworks could share some code + common config that does this, seems to be something simple (and something that all could use for pre-testing validation of all the expected services being alive/active/up/responding...)</span><span style="font-size:12.8000001907349px">?</span></blockquote><div><br></div><div>In Rally this is part of life cycle of running task. </div><div>Not sure that it is possible to share it, because it is thigh related to checking what did you write in task. =)</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 9:54 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/07/2015 02:29 PM, Joshua Harlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Boris Pavlovic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sean,<br>
<br>
Nobody is able to track and know *everything*.<br>
<br>
Friendly reminder that Heat is going to be removed and not installed by<br>
default would help to avoid such situations.<br>
</blockquote>
Doesn't keystone have a service listing? Use that in rally (and<br>
elsewhere?), if keystone had a service and each service had a API<br>
discovery ability, there u go, profit! ;)<br>
</blockquote>
<br>
Service listing for test jobs is actually quite dangerous, because then<br>
something can change something about which services are registered, and<br>
you automatically start skipping 30% of your tests because you react<br>
correctly to this change. However, that means the job stopped doing what<br>
you think it should do.<br>
<br>
*This has happened multiple times in the past*. And typically days,<br>
weeks, or months go by before someone notices in investigating an<br>
unrelated failure. And then it's days, weeks, or months to dig out of<br>
the regressions introduced.<br>
<br>
So... test jobs should be extremely explicit about what they setup and<br>
what they expect.<br>
</blockquote>
<br></span>
Makes sense, perhaps all the test (and/or test-like) frameworks could share some code + common config that does this, seems to be something simple (and something that all could use for pre-testing validation of all the expected services being alive/active/up/responding...)?<br>
<br>
^^ Just an idear,<br>
<br>
-Josh<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
        -Sean<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></div></blockquote></div><br></div>