
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@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...