<div dir="ltr">Hi Ken,<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">I am guessing the above "restart nodes" is for verifying each<br>OpenStack service restarts successfully, right?</blockquote><div><span style="font-size:12.8px">Yes, this is right. And we also will check that HA logic for these</span></div><div><span style="font-size:12.8px">services works correctly (for example, rescheduling of L3 Neutron</span></div><div><span style="font-size:12.8px">agents for </span><span style="font-size:12.8px">networks).</span></div><div><span style="font-size:12.8px"><br></span></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">But these service scripts are provided by distributors, and Devstack<br>itself doesn't contain service scripts IIUC.<br>So I'd like to know how to verify it on Devstack clouds.</blockquote><div><span style="font-size:12.8px">Yes, DevStack doesn't support many scenarios which are actual</span></div><div><span style="font-size:12.8px">and should be supported </span><span style="font-size:12.8px">on the production clouds</span><span style="font-size:12.8px">.</span></div><div><span style="font-size:12.8px">It will be not possible to run all advanced test scenarios for DevStack clouds,</span></div><div><span style="font-size:12.8px">just because DevStack can't deploy OpenStack cloud with 3 controllers</span></div><div><span style="font-size:12.8px">now (so, probably </span><span style="font-size:12.8px">it will be possible </span><span style="font-size:12.8px">in the future).</span></div><div><span style="font-size:12.8px"><br></span></div><div>Of course, some advanced scenarios will support DevStack clouds,</div><div>for example, some test scenarios which are based on customer-found</div><div>issues from the real production clouds, like upload of the large images (100+ Gb)</div><div>to Glance with Swift backend. Such cases are important for verification of</div><div>pre-production environments, but not very important for CI gate jobs.</div><div><br></div><div>It is also important to note that in these advanced cases we are targeting</div><div>to check not only the logic of Python code, but also the correct configuration</div><div>of all OpenStack components on some pre-production OpenStack clusters.</div><div><br></div><div>Thank you!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 2:37 AM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Timur,<br>
<br>
Thanks for picking this up, that is interesting for me.<br>
<span class=""><br>
2016-09-22 5:58 GMT-07:00 Timur Nurlygayanov <<a href="mailto:tnurlygayanov@mirantis.com">tnurlygayanov@mirantis.com</a>>:<br>
><br>
> we have an idea to create the test suite with destructive/HA and advanced<br>
> end-user scenarios for the OpenStack clusters. This test suite will contains<br>
> advanced scenario integration tests for OpenStack clusters to make sure that<br>
> the cluster is ready for the production.<br>
><br>
> The test cases which we want to cover in this test suite:<br>
> 1) All simple and advanced destructive actions, like a reboot of the nodes,<br>
> restart OpenStack services and etc. (we can probably use of-faults library<br>
> [1], which we already use in Rally)<br>
> 2) All advanced test scenarios like a migration of the bunch of VMs between<br>
> nodes and booting of the VMs with large images (10+ Gb), send traffic<br>
> between VMs and in parallel restart Neutron l3 agents and etc.<br>
><br>
> The key requirements:<br>
> 1) The framework should know the details of the deployments (how many nodes<br>
> we have, how to ssh to OpenStack nodes, how to restart the nodes and etc.).<br>
> This is why we don't want to add such "advanced" and HA-focused test<br>
> scenarios to Tempest.<br>
<br>
</span>Yeah, this point is right. This "advanced" way is different from the<br>
design principle of Tempest[1].<br>
I am guessing the above "restart nodes" is for verifying each<br>
OpenStack service restarts successfully, right?<br>
For productions(or distributions), this verifying point seems<br>
important because service scripts need to restart OpenStack services<br>
automatically.<br>
But these service scripts are provided by distributors, and Devstack<br>
itself doesn't contain service scripts IIUC.<br>
So I'd like to know how to verify it on Devstack clouds.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
---<br>
<br>
[1]: <a href="https://github.com/openstack/tempest#design-principles" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>tempest#design-principles</a><br>
<span class=""><br>
> 2) We should be ready to run these tests for any clouds: DevStack clouds (we<br>
> can skip HA cases for DevStack), Fuel clouds, clouds which were deployed by<br>
> Ansible or Puppet tools.<br>
> 3) This framework should allow reproduce the issue in a repeatable manner,<br>
> this is why we can't just cover all the tests with Rally load tests +<br>
> destructive plugins (we are working on this right now too to have an ability<br>
> to test HA-related scenarios under the load).<br>
><br>
> As we discussed on the OpenStack summit a year ago it is better to move such<br>
> test suite in a separate repository and this framework can became a part of<br>
> the QA (or at least BigTent) program in OpenStack.<br>
><br>
> I've created the commit to OpenStack project-config repository:<br>
> <a href="https://review.openstack.org/#/c/374667/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/374667/</a><br>
><br>
> Could you please take a look?<br>
><br>
> We understand that it will be hard to add such test suite to the gates for<br>
> every commit in OpenStack because we will need a lot of hardware. We don't<br>
> want to add these tests to the per-commit gates for now, it is ok to run<br>
> them just once a day, for example. And we definitely need to have such test<br>
> suite to validate our own pre-production clouds.<br>
<br>
</span>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><font color="#888888"><br></font></font><div style="font-family:arial;font-size:small">Timur,</div><div style="font-family:arial;font-size:small">Senior QA Manager</div><div style="font-family:arial;font-size:small">OpenStack Projects</div><div style="font-family:arial;font-size:small">Mirantis Inc</div></div></div></div></div></div></div></div></div>
</div>