Re: [openstack-dev] [Fuel] About deployment progress calculation

2015-01-05 Thread Andrew Woodward
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: 1, 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


Re: [openstack-dev] [Fuel] About deployment progress calculation

2014-11-28 Thread Evgeniy L
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: 1, 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