17:03:48 #startmeeting self-healing 17:03:48 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:51 The meeting name has been set to 'self_healing' 17:03:57 OK 17:04:03 #topic automated testing 17:04:10 I studied about the tools that are being used for testing Openstack and compiled some notes about them. 17:04:17 great! 17:04:25 where would be a good place to put it online and I can improve it further overtime? 17:04:40 depends somewhat on the format 17:04:44 It's not much detailed, I think I can format/categorize it a better way. 17:04:47 markdown 17:04:51 great 17:05:05 ideal would be .rst then we could incorporate into our Sphinx docs 17:05:13 it is easy to convert .md to .rst, e.g. via pandoc 17:05:25 alright I will do that, it shouldn't be a problem 17:05:28 awesome 17:05:48 besides that I did looked more into Eris docs 17:06:01 https://docs.openstack.org/self-healing-sig/latest/meta/CONTRIBUTING.html 17:06:14 https://opendev.org/openstack/self-healing-sig 17:06:29 ah okay, thanks 17:06:33 what did you find? 17:07:24 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 Yes that sounds right 17:08:12 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 oh interesting 17:08:31 I thought they decided not to use os-faults 17:08:39 I guess they must have changed their mind 17:09:11 yes they ended up using it 17:09:34 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 OK great 17:10:41 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 Yes, I agree we need a high level map 17:11:12 of the whole landscape 17:12:42 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 and that's about it from my side :) 17:14:49 OK great 17:15:05 so please submit your .rst to Gerrit and I'll happily review 17:15:33 alright will do, thanks 17:15:33 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 I'm assuming you haven't done it before but maybe you have 17:16:03 sure will let you know, yes haven't used it before 17:16:20 cool 17:16:27 alright I guess we can finish for today 17:16:36 thanks a lot for the update and all the work on this, it's much needed! 17:16:59 thank you! :-) 17:17:13 catch you soon :) 17:17:16 #endmeeting