17:03:48 <aspiers> #startmeeting self-healing
17:03:48 <openstack> Meeting started Wed Jul 31 17:03:48 2019 UTC and is due to finish in 60 minutes.  The chair is aspiers. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:51 <openstack> The meeting name has been set to 'self_healing'
17:03:57 <aspiers> OK
17:04:03 <aspiers> #topic automated testing
17:04:10 <ihti> I studied about the tools that are being used for testing Openstack and compiled some notes about them.
17:04:17 <aspiers> great!
17:04:25 <ihti> where would be a good place to put it online and I can improve it further overtime?
17:04:40 <aspiers> depends somewhat on the format
17:04:44 <ihti> It's not much detailed, I think I can format/categorize it a better way.
17:04:47 <ihti> markdown
17:04:51 <aspiers> great
17:05:05 <aspiers> ideal would be .rst then we could incorporate into our Sphinx docs
17:05:13 <aspiers> it is easy to convert .md to .rst, e.g. via pandoc
17:05:25 <ihti> alright I will do that, it shouldn't be a problem
17:05:28 <aspiers> awesome
17:05:48 <ihti> besides that I did looked more into Eris docs
17:06:01 <aspiers> https://docs.openstack.org/self-healing-sig/latest/meta/CONTRIBUTING.html
17:06:14 <aspiers> https://opendev.org/openstack/self-healing-sig
17:06:29 <ihti> ah okay, thanks
17:06:33 <aspiers> what did you find?
17:07:24 <ihti> checked out the specs and design, but in process of reviewing the actual implementation. From what I see from their docs the plan was/is to have a framework which could do the following types of testing: 1) Control Plane & Data Plane performance 2) Resilency to failure - destructive testing 3) Scalability & concurrency testing.
17:07:36 <aspiers> Yes that sounds right
17:08:12 <ihti> From the initial look of implementation(demo) it seems like they developed an initial version(called as 'pre,pre, alpha' version) which integrated Rally(for Control plane testing) and os-faults(for failure injection) to do destructive testing.
17:08:24 <aspiers> oh interesting
17:08:31 <aspiers> I thought they decided not to use os-faults
17:08:39 <aspiers> I guess they must have changed their mind
17:09:11 <ihti> yes they ended up using it
17:09:34 <ihti> I will check it out more and try to run the demo of Eris in order to get hands-on experience of Rally and os-faults as till now I just have been reading about these tools.
17:09:40 <aspiers> OK great
17:10:41 <ihti> The eris documents do have ideas/goals and some architecture/design as well so we need to figure out how we can achieve this i.e chalkout a rough roadmap and which tools can be used and integrated to cover all these different type of non-functional testing into creation of the framework.
17:11:09 <aspiers> Yes, I agree we need a high level map
17:11:12 <aspiers> of the whole landscape
17:12:42 <ihti> yes that would help with the direction and prioritization, but may be in the mean time I try to get more details out of the docs/implementation.
17:13:50 <ihti> and that's about it from my side :)
17:14:49 <aspiers> OK great
17:15:05 <aspiers> so please submit your .rst to Gerrit and I'll happily review
17:15:33 <ihti> alright will do, thanks
17:15:33 <aspiers> let me know if you have any questions about the Gerrit process but it's very well documented so hopefully straight-forward
17:15:48 <aspiers> I'm assuming you haven't done it before but maybe you have
17:16:03 <ihti> sure will let you know, yes haven't used it before
17:16:20 <aspiers> cool
17:16:27 <aspiers> alright I guess we can finish for today
17:16:36 <aspiers> thanks a lot for the update and all the work on this, it's much needed!
17:16:59 <ihti> thank you! :-)
17:17:13 <aspiers> catch you soon :)
17:17:16 <aspiers> #endmeeting