Open Stack

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 <eli at 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 <dshulyak at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrew
Mirantis
Ceph community