<div dir="ltr"><div>Sam, </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"> Etherpad: </span><a href="https://etherpad.openstack.org/p/SYD-extreme-testing" rel="noreferrer" target="_blank" style="font-size:12.8px">https://etherpad.openstack.<wbr>org/p/SYD-extreme-testing</a></blockquote><div><br></div><div>I really don't want to sound like a person that say use Rally my best ever project blablbab and other BS. </div><div>I think that "reinventing wheels" approach is how humanity evolves and that's why I like this effort in any case. </div><div><br></div><div>But really, I read carefully etherpad and I really see in description of Eris just plain Rally as is: </div><div><br></div><div>- Rally allows you to create tests as YAML </div><div>- Rally allows you to inject in various actions during the load (Rally Hooks) which makes it easy to do chaos and other kind of testing</div><div>- Rally is pluggable and you can write even your own Runners (scenario executors) that will generate load pattern that you need </div><div>- Rally has SLAs plugins (that can deeply analyze result of test cases) and say whatever they pass or not</div><div>- We are working on feature that allows you to mix different workloads in parallel (and generate more realistic load) </div><div>-.....</div><div><br></div><div>So it would be really nice if you can share gaps that you faced that are blocking you to use directly Rally.. </div><div><br></div><div>Thanks!</div><div><br></div><div>Best regards,</div><div>Boris Pavlovic  <div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 31, 2017 at 10:50 PM, Sam P <span dir="ltr"><<a href="mailto:sam47priya@gmail.com" target="_blank">sam47priya@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 All,<br>
<br>
 Sending out a gentle reminder of Sydney Summit Forum Session<br>
regarding this topic.<br>
<br>
 Extreme/Destructive Testing<br>
 Tuesday, November 7, 1:50pm-2:30pm<br>
 Sydney Convention and Exhibition Centre - Level 4 - C4.11<br>
 [<a href="https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20470/extremedestructive-testing" rel="noreferrer" target="_blank">https://www.openstack.org/<wbr>summit/sydney-2017/summit-<wbr>schedule/events/20470/<wbr>extremedestructive-testing</a>]<br>
 Eatherpad: <a href="https://etherpad.openstack.org/p/SYD-extreme-testing" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/SYD-extreme-testing</a><br>
<br>
 Your participation in this session would be greatly appreciated.<br>
--- Regards,<br>
Sampath<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, Aug 14, 2017 at 11:43 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> +1 for Boris’ suggestion. Many of us use Rally to probe our clouds and have<br>
> significant tooling behind it to integrate with local availability reporting<br>
> and trouble ticketing systems. It would be much easier to deploy new<br>
> functionality such as you propose if it was integrated into an existing<br>
> project framework (such as Rally).<br>
><br>
><br>
><br>
> Tim<br>
><br>
><br>
><br>
> From: Boris Pavlovic <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>><br>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
> Date: Monday, 14 August 2017 at 12:57<br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
> Cc: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
> Subject: Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme<br>
> Testing<br>
><br>
><br>
><br>
> Sam,<br>
><br>
><br>
><br>
> Seems like a good plan and huge topic ;)<br>
><br>
><br>
><br>
> I would as well suggest to take a look at the similar efforts in OpenStack:<br>
><br>
> - Failure injection: <a href="https://github.com/openstack/os-faults" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>os-faults</a><br>
><br>
> - Rally Hooks Mechanism (to inject in rally scenarios failures):<br>
> <a href="https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_trigger_plugins.html" rel="noreferrer" target="_blank">https://rally.readthedocs.io/<wbr>en/latest/plugins/<wbr>implementation/hook_and_<wbr>trigger_plugins.html</a><br>
><br>
><br>
><br>
><br>
><br>
> Best regards,<br>
> Boris Pavlovic<br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Aug 14, 2017 at 2:35 AM, Sam P <<a href="mailto:sam47priya@gmail.com">sam47priya@gmail.com</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> This is a follow up for OpenStack Extreme Testing session[1]<br>
> we did in MEX-ops-meetup.<br>
><br>
> Quick intro for those who were not there:<br>
> In this work, we proposed to add new testing framework for openstack.<br>
> This framework will provides tool for create tests with destructive<br>
> scenarios which will check for High Availability, failover and<br>
> recovery of OpenStack cloud.<br>
> Please refer the link on top of the [1] for further details.<br>
><br>
> Follow up:<br>
> We are planning periodic irc meeting and have an irc<br>
> channel for discussion. I will get back to you with those details soon.<br>
><br>
> At that session, we did not have time to discuss last 3 items,<br>
> Reference architectures<br>
>  We are discussing about the reference architecture in [2].<br>
><br>
> What sort of failures do you see today in your environment?<br>
>  Currently we are considering, service failures, backend services (mq,<br>
> DB, etc.) failures,<br>
>  Network sw failures..etc. To begin with the implementation, we are<br>
> considering to start with<br>
>  service failures. Please let us know what failures are more frequent<br>
> in your environment.<br>
><br>
> Emulation/Simulation mechanisms, etc.<br>
>  Rather than doing actual scale, load, or performance tests, we are<br>
> thinking to build a emulation/simulation mechanism<br>
> to get the predictions or result of how will openstack behave on such<br>
> situations.<br>
> This interesting idea was proposed by the Gautam and need more<br>
> discussion on this.<br>
><br>
> Please let us know you questions or comments.<br>
><br>
> Request to Mike Perez:<br>
>  We discussed about synergies with openstack assertion tags and other<br>
> efforts to do similar testing in openstack.<br>
>  Could you please give some info or pointer of previous discussions.<br>
><br>
> [1] <a href="https://etherpad.openstack.org/p/MEX-ops-extreme-testing" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/MEX-ops-extreme-testing</a><br>
> [2]<br>
> <a href="https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/15477787/Extreme+Testing-Vision+Arch" rel="noreferrer" target="_blank">https://openstack-lcoo.<wbr>atlassian.net/wiki/spaces/<wbr>LCOO/pages/15477787/Extreme+<wbr>Testing-Vision+Arch</a><br>
><br>
> --- Regards,<br>
> Sampath<br>
><br>
> ______________________________<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>
><br>
><br>
><br>
><br>
> ______________________________<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>
><br>
<br>
______________________________<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>
</div></div></blockquote></div><br></div>