Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141128/1babf5d8/attachment.html>