7:02 p.m.
On 01/01/2012 11:38 PM, Itamar Heim wrote:
On 01/01/2012 02:39 AM, Moti Asayag wrote:
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
looks pretty comprehensive - a few questions:
1. can one see all audit log events related to a task?
It means to apply a search
query for the event log by job id.
The job id is associated with the audit log, therefore such query could
be comprised. This will probably be enabled from the global Tasks view.
2. "A command with VDSM tasks" - what about other types of tasks? what
if after the vdsm tasks there is another part of logic, then another
vdsm task (iirc, there was a legacy limitation of "one single async task
in the end of the command", but this shouldn't be relevant any more).
The
Step entity is associated with external_system_type and external_id
which in this case are correlated to VDSM (external system type) and
VDSM task id (external id).
Having additional external systems which the backend invokes tasks on
will be supported if the task on the external system could be associated
with its representing Step and the task could be queried for it status.
VDSM Tasks which are created by a command will be polled only after the
command execution is over. If the command failed in between the creation
of Tasks due to some runtime exception, the command should be
rolled-back and the VDSM tasks should be cancelled and cleared. If
execution ends, by polling VDSM task status the step representing each
task should be updated with the task status. An example for such command
is HibernateVmCommand.
3. "A command which invokes internal commands - By default, the internal
command will not be presented as a step of the parent command."
examples of the non default behavior?
For example the MaintenanceNumberOfVdsCommand
which invokes
MaintenanceVdsCommand which invokes InternalMigrateVmCommand.
Those are significant steps which we should expose to the user.
4. "A customized command - an asynchronous job which its termination is
decided by an event other than tasks. There are few types of scenarios
for it"
the examples are all described as internal implementation details - what
are some actual relevant use cases/flows and what will the user see for
them?
you also mention AddVdsCommand here - will it's internal steps be
visible to the user as part of the monitored task?
AddVdsCommand is an example for
the above as its execution is durable
due to the installation part that should be exposed as a step to the user.
Another example is the determination of completing the
MaintenanceVdsCommand by receiving an event from the host monitor for
host moved to maintenance. It is already a step created earlier, but its
completion will be due to this specific event.
5. requirements: what about internal tasks originated by the system (SPM
election, live migration due to load balancing, fencing taking place,
refresh of users from a directory, etc.)?
It was discussed on the meeting held
today. It was agreed to report for
specific internal action such as VM migration, Host fencing,... but not
for the event itself (in order to prevent from flooding the Tasks view
from frequent events).
6. STEP table, start_time is "not null" - shouldn't it be nullable?
No. The Step is created in adjust to the execution unit it describes. In
order to prevent from additional update, it should be created with
status Started and start time.
7. UX - no main tasks view?
Eldan, Einav ?
8. can i define a step based on a previous step failure rather than
success (i.e., step 2 will be run only if step 1 succeeds, step 3 will
only run if step 1 failed, step 4 could be either dependent on any of
them, or run after step 2 and 3 finished, whatever their result was.
It requires
introducing the "best effort step" (V2), a failure of a step
will not fail the entire job. Mixing it with customized command should
provide that behavior. However, the Steps are used to report on
execution units status and do not participate in handling the flow.
9. REST API modeling?
On the way...