<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>