On 01/02/2012 12:34 PM, Maor wrote:
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,
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