<div dir="ltr">Ilya,<div><br></div><div>It sounds good, moreover few other devs asked about similar feature=)</div><div>So I am working on proposal how to implement this=)</div><div><br></div><div><br></div><div>Best regards,</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 4:35 PM, Ilya Shakhat <span dir="ltr"><<a href="mailto:ishakhat@mirantis.com" target="_blank">ishakhat@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ralliers, <div><br></div><div>I'd like to share with you an idea on how to test dependent resources.</div><div><br></div><div>Let's consider the following example: there is a network and ports belonging to it and we would like to test port creation process. Currently I see 2 options of writing scenario:</div><div> a) The scenario creates network and then creates a specified number of ports. Runner executes the scenario specified number of times. -- In this case ports belonging to different networks are created in parallel, but all ports belonging to the same network are created serially. </div><div> b) The network already exists and the scenario just creates ports, -- This case allows to test concurrent creation of ports belonging to the same network but not between multiple networks.</div><div>It would be really cool to get benefits from both cases, i.e. to test parallel port creation but without limiting to parent network resource. <br></div><div><br></div><div>One of possible approaches may be to construct chain of scenarios where preceding scenario prepares context for the further one. From the above example the execution would be:</div><div> 1) The task contains sequence of 2 scenarios: </div><div>    * network creation - it creates network and returns it</div><div>    * port creation - it picks the network from incoming params and creates port on it</div><div> 2) The runner has execution pipeline (which currently is represented as generator producing identical scenario runners). The pipeline starts with sequence of network creation scenario runners. Once one of runner finishes, it then puts the further scenario and the result into pipeline. The pipeline ends once no further scenarios left. </div><div><br></div><div>From the above example execution flow would be like:</div><div> * pipeline is "filled" with N network scenarios (not actually filled, but contains a generator that is able to do this)</div><div> * R runners pick scenarios from pipeline</div><div> * pipeline contains N-R network scenarios</div><div> * one of runners finishes the scenario and updates pipeline with P port scenarios</div><div> * pipeline contains N-R-1 network scenarios followed by P port scenarios</div><div> * work-work-work until pipeline is empty</div><div><br></div><div>This execution covers case from a) and b) but there still will be sequences of child resources belonging to the same parent. The improvement may be to pick scenario from pipeline randomly.</div><div><br></div><div>How does it sound?</div><div><br></div><div>Thanks,</div><div>Ilya</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br></div>