Hi Moti, I got a few questions regarding the Task Manager design:
Do we still need zombie tasks after this change, since I saw the user can now end the process from the GUI?
What should be the behaviour when user will try to end step deleteVolume from the GUI? How will it reflect the entire Job? Task management is not in scope for 3.1 drop 1, only task monitoring,
On 01/02/2012 12:34 PM, Maor wrote: therefore current behavior is maintained.
Referencing DB scope, Will step_name and external_system_type will be reflected by enums? if they are, maybe its better to use int instead of String in those fields.
On discussion held in [1], it was suggested to prefer varchar for enum fields as early step before using the enum type (postgres 9.1). I'll update the rest of enum value-based fields to type varchar. [1] http://lists.ovirt.org/pipermail/engine-devel/2011-December/000258.html
Would not it be better to declare correlation_id and external_id as UUID instead of String. The correlation id id provided by the client and its structure is not being enforced. From client PoV, they could set a value of UUID_Connect-to-local-storage as the correlation-id.
I'll update the external-id to Guid
Does the task name is calculated on create, or should it be persisted in the DB?
In order to skip the need for resolving the step description on clients, and to refrain from saving the context of the Step (which entities a specific step describes), I'll add a field named 'description' (UTF8 by DB definition) which is evaluated on the creation of the Step and should be the presentation name of the step (same as appeared in mockups).
Besides that, looks very good!
Regards, Maor Lipchuk