<div dir="ltr">Hi Dmitry,<div><br></div><div>I totally agree that the current approach won't work (and doesn't work well).</div><div><br></div><div>I have several comments:</div><div><br></div><div>>> <span style="font-family:arial,sans-serif;font-size:13px">Each task will provide estimated time</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>1. Each task has timeout, lets use it as an estimate, I don't think</div><div> that we should ask to provide both of this fields, execution</div><div> estimate depends on hardware, my suggestion is to keep it</div><div> simple and solve the problem internally with information from</div><div> timeout field.</div><div>2. I would like to clarify implementation a bit more, what is</div><div> "<span style="font-family:arial,sans-serif;font-size:13px">time delta of the task"? I think that Task executor (</span><span style="font-family:arial,sans-serif;font-size:13px">orchestrator/astute/mistral)</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"> shouldn't provide any information except status of the task,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"> it should be simple interface, like "task_uuid: 11111, status: running"</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"> and Nailgun on its side should do all of the magic with progress calculation.</span></div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 10:29 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@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">Hello everyone,<div><br></div><div>I want to raise concerns about progress bar, and its usability.</div><div>In my opinion current approach has several downsides:</div><div>1. No valuable information</div><div>2. Very fragile, you need to change code in several places not to break it</div><div>3. Will not work with plugable code</div><div><br></div><div>Log parsing works under one basic assumption - that we are in control of all tasks,</div><div>so we can use mappings to logs with certain pattern.</div><div> It wont work with plugable architecture, and i am talking not about fuel-plugins, and the</div><div>way it will be done in 6.0, but the whole idea of plugable architecture, and i assume that internal features will be implemented as granular self-contained plugins, </div><div>and it will be possible to accomplish not only with puppet, but with any other tool that suits you.</div><div>Asking person who will provide plugin (extension) to add mappings to logs - feels like weirdeist thing ever.</div><div><br></div><div><u>What can be done to improve usability of progress calculation?</u></div><div>I see here several requirements:</div><div>1.Provide valuable information</div><div> - Correct representation of time that task takes to run</div><div> - What is going on target node in any point of the deployment?</div><div>2. Plugin friendly, it means that approach we will take should be flexible and extendable</div><div><br></div><div><u>Implementation:</u></div><div><div>In nearest future deployment will be splitted into tasks, they are will be big, not granular</div><div>(like deploy controller, deploy compute), but this does not matter, because we can start to estimate them.</div><div>Each task will provide estimated time. </div></div><div>At first it will be manually setted by person who develops plugin (tasks), but it can be improved, </div><div>so this information automatically (or semi-auto) will be provided by fuel-stats application.</div><div>It will require orchestrator to report 2 simple entities:</div><div>- time delta of the task</div><div>- task identity</div><div>UI will be able to show percents anyway, but additionally it will show what is running on target node.</div><div><br></div><div>Ofcourse it is not about 6.0, but please take a look, and lets try to agree</div><div>on what is right way to solve this task, because log parsing will not work with data-driven</div><div>orchestrator and plugable architecture.</div><div>Thank you</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>