Sorry for the necro-post but I think it's important to note that as we get more progress with granular roles, we get specific tasks, and time-out durations for not just plugin tasks, but all tasks. As Evegniy noted, we should be able to use this as a calibration of the ceiling of the progress bars. Without other data, we could assume that 1/2 the timeout is the expected run time of the task
I think we can and should use data from the stats collection to figure the average, and possibly re-calibrate the timeouts for the tasks. On Fri, Nov 28, 2014 at 5:21 AM, Evgeniy L <e...@mirantis.com> wrote: > Hi Dmitry, > > I totally agree that the current approach won't work (and doesn't work > well). > > I have several comments: > >>> Each task will provide estimated time > > 1. Each task has timeout, lets use it as an estimate, I don't think > that we should ask to provide both of this fields, execution > estimate depends on hardware, my suggestion is to keep it > simple and solve the problem internally with information from > timeout field. > 2. I would like to clarify implementation a bit more, what is > "time delta of the task"? I think that Task executor > (orchestrator/astute/mistral) > shouldn't provide any information except status of the task, > it should be simple interface, like "task_uuid: 11111, status: running" > and Nailgun on its side should do all of the magic with progress > calculation. > > Thanks, > > On Tue, Oct 28, 2014 at 10:29 AM, Dmitriy Shulyak <dshul...@mirantis.com> > wrote: >> >> Hello everyone, >> >> I want to raise concerns about progress bar, and its usability. >> In my opinion current approach has several downsides: >> 1. No valuable information >> 2. Very fragile, you need to change code in several places not to break it >> 3. Will not work with plugable code >> >> Log parsing works under one basic assumption - that we are in control of >> all tasks, >> so we can use mappings to logs with certain pattern. >> It wont work with plugable architecture, and i am talking not about >> fuel-plugins, and the >> 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, >> and it will be possible to accomplish not only with puppet, but with any >> other tool that suits you. >> Asking person who will provide plugin (extension) to add mappings to logs >> - feels like weirdeist thing ever. >> >> What can be done to improve usability of progress calculation? >> I see here several requirements: >> 1.Provide valuable information >> - Correct representation of time that task takes to run >> - What is going on target node in any point of the deployment? >> 2. Plugin friendly, it means that approach we will take should be flexible >> and extendable >> >> Implementation: >> In nearest future deployment will be splitted into tasks, they are will be >> big, not granular >> (like deploy controller, deploy compute), but this does not matter, >> because we can start to estimate them. >> Each task will provide estimated time. >> At first it will be manually setted by person who develops plugin (tasks), >> but it can be improved, >> so this information automatically (or semi-auto) will be provided by >> fuel-stats application. >> It will require orchestrator to report 2 simple entities: >> - time delta of the task >> - task identity >> UI will be able to show percents anyway, but additionally it will show >> what is running on target node. >> >> Ofcourse it is not about 6.0, but please take a look, and lets try to >> agree >> on what is right way to solve this task, because log parsing will not work >> with data-driven >> orchestrator and plugable architecture. >> Thank you >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Andrew Mirantis Ceph community _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev