10:39 a.m.
--=_3b1fbb3e-f4ad-474a-8ab2-bf0931975a42
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
The following is a new meeting request:
Subject: Task Manager Design Review
Organizer: "Moti Asayag" <masayag(a)redhat.com>
Location: asia-tlv(a)redhat.com
Resources: asia-tlv(a)redhat.com
Time: Monday, January 2, 2012, 2:00:00 PM - 3:00:00 PM GMT +02:00 Jerusalem
Invitees: engine-devel(a)ovirt.org; mgoldboi(a)redhat.com; ykaul(a)redhat.com
*~*~*~*~*~*~*~*~*~*
This is an invitation for a design review for the Task Manager feature.
Task Manager Detailed design could be found here:
http://ovirt.org/wiki/Features/TaskManagerDetailed
You are invited to join.
== Conference Call Info ==
* Toll Free Dial-In Number (US & Canada): (800) 451-8679
* International dial-in listed below
* Conference Code: 9197544554
If you are not actively participating in the conversation
please put your line on mute to make it easier for all
participants to hear.
*6 -- Mute your line
#6 -- Unmute your line
Global Access Numbers Local:
Australia, Sydney Dial-In #: 0289852326
Austria, Vienna Dial-In #: 012534978196
Belgium, Brussels Dial-In #: 027920405
China Dial-In #: 4006205013
Denmark, Copenhagen Dial-In #: 32729215
Finland, Helsinki Dial-In #: 0923194436
France, Paris Dial-In #: 0170377140
Germany, Berlin Dial-In #: 030300190579
Ireland, Dublin Dial-In #: 014367793
Italy, Milan Dial-In #: 0236269529
Netherlands, Amsterdam Dial-In #: 0207975872
Norway, Oslo Dial-In #: 21033188
Singapore Dial-In #: 64840858
Spain, Barcelona Dial-In #: 935452328
Sweden, Stockholm Dial-In #: 0850513770
Switzerland, Geneva Dial-In #: 0225927881
United Kingdom Dial-In #: 02078970515
United Kingdom Dial-In #: 08445790676
United Kingdom, LocalCall Dial-In #: 08445790678
United States Dial-In #: 2127295016
Global Access Numbers Tollfree:
Argentina Dial-In #: 8004441016
Australia Dial-In #: 1800337169
Austria Dial-In #: 0800005898
Bahamas Dial-In #: 18002054776
Bahrain Dial-In #: 80004377
Belgium Dial-In #: 080048325
Brazil Dial-In #: 08008921002
Bulgaria Dial-In #: 008001100236
Chile Dial-In #: 800370228
Colombia Dial-In #: 018009134033
Costa Rica Dial-In #: 08000131048
Cyprus Dial-In #: 80095297
Czech Republic Dial-In #: 800700318
Denmark Dial-In #: 80887114
Dominican Republic Dial-In #: 18887512313
Estonia Dial-In #: 8000100232
Finland Dial-In #: 0800117116
France Dial-In #: 0805632867
Germany Dial-In #: 8006647541
Greece Dial-In #: 00800127562
Hong Kong Dial-In #: 800930349
Hungary Dial-In #: 0680016796
Iceland Dial-In #: 8008967
India Dial-In #: 0008006501533
Indonesia Dial-In #: 0018030179162
Ireland Dial-In #: 1800932401
Israel Dial-In #: 1809462557
Italy Dial-In #: 800985897
Jamaica Dial-In #: 18002050328
Japan Dial-In #: 0120934453
Korea (South) Dial-In #: 007986517393
Latvia Dial-In #: 80003339
Lithuania Dial-In #: 880030479
Luxembourg Dial-In #: 80026595
Malaysia Dial-In #: 1800814451
Mexico Dial-In #: 0018664590915
New Zealand Dial-In #: 0800888167
Norway Dial-In #: 80012994
Panama Dial-In #: 008002269184
Philippines Dial-In #: 180011100991
Poland Dial-In #: 008001210187
Portugal Dial-In #: 800814625
Russian Federation Dial-In #: 81080028341012
Saint Kitts and Nevis Dial-In #: 18002059252
Singapore Dial-In #: 8006162235
Slovak Republic Dial-In #: 0800001441
South Africa Dial-In #: 0800981148
Spain Dial-In #: 800300524
Sweden Dial-In #: 200896860
Switzerland Dial-In #: 800650077
Taiwan Dial-In #: 00801127141
Thailand Dial-In #: 001800656966
Trinidad and Tobago Dial-In #: 18002024615
United Arab Emirates Dial-In #: 8000650591
United Kingdom Dial-In #: 08006948057
United States Dial-In #: 8004518679
Uruguay Dial-In #: 00040190315
Venezuela Dial-In #: 08001627182
--=_3b1fbb3e-f4ad-474a-8ab2-bf0931975a42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><h3>The following is a new meeting request:</h3>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Subject:</th><td>Task Manager Design Review
</td></tr>=
<tr><th align=3Dleft>Organizer:</th><td>"Moti Asayag"
&lt;masayag(a)redhat.co=
m> </td></tr>
</table>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Location:</th><td>asia-tlv@redhat.com
</td></tr>
<tr><th align=3Dleft>Resources:</th><td>asia-tlv@redhat.com
</td></tr>
<tr><th align=3Dleft>Time:</th><td>Monday, January 2, 2012,
2:00:00 PM - 3:=
00:00 PM GMT +02:00 Jerusalem
</td></tr></table>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Invitees:</th><td>engine-devel@ovirt.org;
mgoldboi@red=
hat.com; ykaul(a)redhat.com </td></tr>
</table>
<div>*~*~*~*~*~*~*~*~*~*</div><br>This is an invitation for a design
review=
for the Task Manager feature.<br>Task Manager Detailed design could be fou=
nd
here:<br>http://ovirt.org/wiki/Features/TaskManagerDetailed<br&g...
a=
re invited to join.<br><br>=3D=3D Conference Call Info
=3D=3D<br><br>* Toll=
Free Dial-In Number (US & Canada): (800) 451-8679<br>* International d=
ial-in listed below<br>* Conference Code: 9197544554<br><br>If you are
not =
actively participating in the conversation<br>please put your line on mute =
to make it easier for all<br>participants to hear.<br><br>*6 -- Mute
your l=
ine<br>#6 -- Unmute your line<br><br>Global Access Numbers
Local:<br>Austra=
lia, Sydney Dial-In #: 0289852326<br>Austria, Vienna Dial-In #: 01253497819=
6<br>Belgium, Brussels Dial-In #: 027920405<br>China Dial-In #:
4006205013<=
br>Denmark, Copenhagen Dial-In #: 32729215<br>Finland, Helsinki Dial-In #: =
0923194436<br>France, Paris Dial-In #: 0170377140<br>Germany, Berlin Dial-I=
n #: 030300190579<br>Ireland, Dublin Dial-In #: 014367793<br>Italy, Milan D=
ial-In #: 0236269529<br>Netherlands, Amsterdam Dial-In #: 0207975872<br>Nor=
way, Oslo Dial-In #: 21033188<br>Singapore Dial-In #: 64840858<br>Spain, Ba=
rcelona Dial-In #: 935452328<br>Sweden, Stockholm Dial-In #: 0850513770<br>=
Switzerland, Geneva Dial-In #: 0225927881<br>United Kingdom Dial-In #: 0207=
8970515<br>United Kingdom Dial-In #: 08445790676<br>United Kingdom, LocalCa=
ll Dial-In #: 08445790678<br>United States Dial-In #:
2127295016<br><br>&nb=
sp;<br>Global Access Numbers Tollfree:<br>Argentina Dial-In #:
8004441016<b=
r>Australia Dial-In #: 1800337169<br>Austria Dial-In #:
0800005898<br>Baham=
as Dial-In #: 18002054776<br>Bahrain Dial-In #: 80004377<br>Belgium Dial-In=
#: 080048325<br>Brazil Dial-In #: 08008921002<br>Bulgaria Dial-In #: 00800=
1100236<br>Chile Dial-In #: 800370228<br>Colombia Dial-In #:
018009134033<b=
r>Costa Rica Dial-In #: 08000131048<br>Cyprus Dial-In #: 80095297<br>Czech
=
Republic Dial-In #: 800700318<br>Denmark Dial-In #: 80887114<br>Dominican R=
epublic Dial-In #: 18887512313<br>Estonia Dial-In #: 8000100232<br>Finland =
Dial-In #: 0800117116<br>France Dial-In #: 0805632867<br>Germany Dial-In #:=
8006647541<br>Greece Dial-In #: 00800127562<br>Hong Kong Dial-In #: 800930=
349<br>Hungary Dial-In #: 0680016796<br>Iceland Dial-In #:
8008967<br>India=
Dial-In #: 0008006501533<br>Indonesia Dial-In #: 0018030179162<br>Ireland =
Dial-In #: 1800932401<br>Israel Dial-In #: 1809462557<br>Italy Dial-In #: 8=
00985897<br>Jamaica Dial-In #: 18002050328<br>Japan Dial-In #:
0120934453<b=
r>Korea (South) Dial-In #: 007986517393<br>Latvia Dial-In #:
80003339<br>Li=
thuania Dial-In #: 880030479<br>Luxembourg Dial-In #: 80026595<br>Malaysia =
Dial-In #: 1800814451<br>Mexico Dial-In #: 0018664590915<br>New Zealand Dia=
l-In #: 0800888167<br>Norway Dial-In #: 80012994<br>Panama Dial-In #: 00800=
2269184<br>Philippines Dial-In #: 180011100991<br>Poland Dial-In #: 0080012=
10187<br>Portugal Dial-In #: 800814625<br>Russian Federation Dial-In #: 810=
80028341012<br>Saint Kitts and Nevis Dial-In #: 18002059252<br>Singapore Di=
al-In #: 8006162235<br>Slovak Republic Dial-In #: 0800001441<br>South Afric=
a Dial-In #: 0800981148<br>Spain Dial-In #: 800300524<br>Sweden Dial-In #: =
200896860<br>Switzerland Dial-In #: 800650077<br>Taiwan Dial-In #: 00801127=
141<br>Thailand Dial-In #: 001800656966<br>Trinidad and Tobago Dial-In #: 1=
8002024615<br>United Arab Emirates Dial-In #: 8000650591<br>United Kingdom =
Dial-In #: 08006948057<br>United States Dial-In #: 8004518679<br>Uruguay Di=
al-In #: 00040190315<br>Venezuela Dial-In #: 08001627182</body></html>
--=_3b1fbb3e-f4ad-474a-8ab2-bf0931975a42
Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=2SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T020000
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:f33aaaff-e736-4f96-8e51-f1df0aecdd59
SUMMARY:Task Manager Design Review
LOCATION:asia-tlv@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
devel(a)ovirt.org
ATTENDEE;CN=Moran Goldboim;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
RUE:mailto:mgoldboi@redhat.com
ATTENDEE;CN=Yaniv Kaul;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:
mailto:ykaul@redhat.com
ATTENDEE;CN=Asia-tlv;CUTYPE=RESOURCE;ROLE=NON-PARTICIPANT;PARTSTAT=NEEDS-ACT
ION;RSVP=TRUE:mailto:asia-tlv@redhat.com
ORGANIZER;CN=Moti Asayag:mailto:masayag@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120102T140000
DTEND;TZID="Asia/Jerusalem":20120102T150000
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20120101T003917Z
DTSTAMP:20120101T003917Z
SEQUENCE:0
DESCRIPTION:The following is a new meeting request:\n\nSubject: Task Manager
Design Review \nOrganizer: "Moti Asayag" <masayag(a)redhat.com>
\n\nLocation:
asia-tlv(a)redhat.com \nResources: asia-tlv(a)redhat.com \nTime: Monday\, Janua
ry 2\, 2012\, 2:00:00 PM - 3:00:00 PM GMT +02:00 Jerusalem\n \nInvitees: eng
ine-devel(a)ovirt.org\; mgoldboi(a)redhat.com\; ykaul(a)redhat.com \n\n\n*~*~*~*~*
~*~*~*~*~*\n\nThis is an invitation for a design review for the Task Manager
feature.\nTask Manager Detailed design could be found here:\nhttp://ovirt.o
rg/wiki/Features/TaskManagerDetailed\n\nYou are invited to join.\n\n== Confe
rence Call Info ==\n\n* Toll Free Dial-In Number (US & Canada): (800) 451-86
79\n* International dial-in listed below\n* Conference Code: 9197544554\n\nI
f you are not actively participating in the conversation\nplease put your li
ne on mute to make it easier for all\nparticipants to hear.\n\n*6 -- Mute yo
ur line\n#6 -- Unmute your line\n\nGlobal Access Numbers Local:\nAustralia\,
Sydney Dial-In #: 0289852326\nAustria\, Vienna Dial-In #: 012534978196\nBel
gium\, Brussels Dial-In #: 027920405\nChina Dial-In #: 4006205013\nDenmark\,
Copenhagen Dial-In #: 32729215\nFinland\, Helsinki Dial-In #: 0923194436\nF
rance\, Paris Dial-In #: 0170377140\nGermany\, Berlin Dial-In #: 03030019057
9\nIreland\, Dublin Dial-In #: 014367793\nItaly\, Milan Dial-In #: 023626952
9\nNetherlands\, Amsterdam Dial-In #: 0207975872\nNorway\, Oslo Dial-In #: 2
1033188\nSingapore Dial-In #: 64840858\nSpain\, Barcelona Dial-In #: 9354523
28\nSweden\, Stockholm Dial-In #: 0850513770\nSwitzerland\, Geneva Dial-In #
: 0225927881\nUnited Kingdom Dial-In #: 02078970515\nUnited Kingdom Dial-In
#: 08445790676\nUnited Kingdom\, LocalCall Dial-In #: 08445790678\nUnited St
ates Dial-In #: 2127295016\n\n \nGlobal Access Numbers Tollfree:\nArgentina
Dial-In #: 8004441016\nAustralia Dial-In #: 1800337169\nAustria Dial-In #: 0
800005898\nBahamas Dial-In #: 18002054776\nBahrain Dial-In #: 80004377\nBelg
ium Dial-In #: 080048325\nBrazil Dial-In #: 08008921002\nBulgaria Dial-In #:
008001100236\nChile Dial-In #: 800370228\nColombia Dial-In #: 018009134033\
nCosta Rica Dial-In #: 08000131048\nCyprus Dial-In #: 80095297\nCzech Republ
ic Dial-In #: 800700318\nDenmark Dial-In #: 80887114\nDominican Republic Dia
l-In #: 18887512313\nEstonia Dial-In #: 8000100232\nFinland Dial-In #: 08001
17116\nFrance Dial-In #: 0805632867\nGermany Dial-In #: 8006647541\nGreece D
ial-In #: 00800127562\nHong Kong Dial-In #: 800930349\nHungary Dial-In #: 06
80016796\nIceland Dial-In #: 8008967\nIndia Dial-In #: 0008006501533\nIndone
sia Dial-In #: 0018030179162\nIreland Dial-In #: 1800932401\nIsrael Dial-In
#: 1809462557\nItaly Dial-In #: 800985897\nJamaica Dial-In #: 18002050328\nJ
apan Dial-In #: 0120934453\nKorea (South) Dial-In #: 007986517393\nLatvia Di
al-In #: 80003339\nLithuania Dial-In #: 880030479\nLuxembourg Dial-In #: 800
26595\nMalaysia Dial-In #: 1800814451\nMexico Dial-In #: 0018664590915\nNew
Zealand Dial-In #: 0800888167\nNorway Dial-In #: 80012994\nPanama Dial-In #:
008002269184\nPhilippines Dial-In #: 180011100991\nPoland Dial-In #: 008001
210187\nPortugal Dial-In #: 800814625\nRussian Federation Dial-In #: 8108002
8341012\nSaint Kitts and Nevis Dial-In #: 18002059252\nSingapore Dial-In #:
8006162235\nSlovak Republic Dial-In #: 0800001441\nSouth Africa Dial-In #: 0
800981148\nSpain Dial-In #: 800300524\nSweden Dial-In #: 200896860\nSwitzerl
and Dial-In #: 800650077\nTaiwan Dial-In #: 00801127141\nThailand Dial-In #:
001800656966\nTrinidad and Tobago Dial-In #: 18002024615\nUnited Arab Emira
tes Dial-In #: 8000650591\nUnited Kingdom Dial-In #: 08006948057\nUnited Sta
tes Dial-In #: 8004518679\nUruguay Dial-In #: 00040190315\nVenezuela Dial-In
#: 08001627182
X-ALT-DESC;FMTTYPE=text/html:<html><body><h3>The following is a new
meeting
request:</h3>\n\n<p>\n<table border='0'>\n<tr><th
align=left>Subject:</th><t
d>Task Manager Design Review </td></tr>\n<tr><th
align=left>Organizer:</th><
td>"Moti Asayag" &lt\;masayag(a)redhat.com&gt\;
</td></tr>\n</table>\n<p>\n<ta
ble border='0'>\n<tr><th
align=left>Location:</th><td>asia-tlv@redhat.com </
td></tr>\n<tr><th
align=left>Resources:</th><td>asia-tlv@redhat.com </td></t
r>\n<tr><th align=left>Time:</th><td>Monday\, January 2\,
2012\, 2:00:00 PM
- 3:00:00 PM GMT +02:00 Jerusalem\n
</td></tr></table>\n<p>\n<table border='
0'>\n<tr><th
align=left>Invitees:</th><td>engine-devel@ovirt.org\; mgoldboi@
redhat.com\; ykaul(a)redhat.com
</td></tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~*
</div><br>This is an invitation for a design review for the Task Manager fea
ture.<br>Task Manager Detailed design could be found here:<br>http://ovirt.o
rg/wiki/Features/TaskManagerDetailed<br><br>You are invited to
join.<br><br>
== Conference Call Info ==<br><br>* Toll Free Dial-In Number (US &\;
Cana
da): (800) 451-8679<br>* International dial-in listed below<br>* Conference
Code: 9197544554<br><br>If you are not actively participating in the convers
ation<br>please put your line on mute to make it easier for all<br>participa
nts to hear.<br><br>*6 -- Mute your line<br>#6 -- Unmute your
line<br><br>Gl
obal Access Numbers Local:<br>Australia\, Sydney Dial-In #: 0289852326<br>Au
stria\, Vienna Dial-In #: 012534978196<br>Belgium\, Brussels Dial-In #: 0279
20405<br>China Dial-In #: 4006205013<br>Denmark\, Copenhagen Dial-In #: 3272
9215<br>Finland\, Helsinki Dial-In #: 0923194436<br>France\, Paris Dial-In #
: 0170377140<br>Germany\, Berlin Dial-In #: 030300190579<br>Ireland\, Dublin
Dial-In #: 014367793<br>Italy\, Milan Dial-In #: 0236269529<br>Netherlands\
, Amsterdam Dial-In #: 0207975872<br>Norway\, Oslo Dial-In #: 21033188<br>Si
ngapore Dial-In #: 64840858<br>Spain\, Barcelona Dial-In #: 935452328<br>Swe
den\, Stockholm Dial-In #: 0850513770<br>Switzerland\, Geneva Dial-In #: 022
5927881<br>United Kingdom Dial-In #: 02078970515<br>United Kingdom Dial-In #
: 08445790676<br>United Kingdom\, LocalCall Dial-In #: 08445790678<br>United
States Dial-In #: 2127295016<br><br> \;<br>Global Access
Numbers Tollfr
ee:<br>Argentina Dial-In #: 8004441016<br>Australia Dial-In #:
1800337169<br
Austria Dial-In #: 0800005898<br>Bahamas Dial-In #:
18002054776<br>Bahrain
Dial-In #: 80004377<br>Belgium Dial-In #:
080048325<br>Brazil Dial-In #: 080
08921002<br>Bulgaria Dial-In #: 008001100236<br>Chile Dial-In #:
800370228<b
r>Colombia Dial-In #: 018009134033<br>Costa Rica Dial-In #:
08000131048<br>C
yprus Dial-In #: 80095297<br>Czech Republic Dial-In #: 800700318<br>Denmark
Dial-In #: 80887114<br>Dominican Republic Dial-In #: 18887512313<br>Estonia
Dial-In #: 8000100232<br>Finland Dial-In #: 0800117116<br>France Dial-In #:
0805632867<br>Germany Dial-In #: 8006647541<br>Greece Dial-In #: 00800127562
<br>Hong Kong Dial-In #: 800930349<br>Hungary Dial-In #:
0680016796<br>Icela
nd Dial-In #: 8008967<br>India Dial-In #: 0008006501533<br>Indonesia Dial-In
#: 0018030179162<br>Ireland Dial-In #: 1800932401<br>Israel Dial-In #: 1809
462557<br>Italy Dial-In #: 800985897<br>Jamaica Dial-In #:
18002050328<br>Ja
pan Dial-In #: 0120934453<br>Korea (South) Dial-In #: 007986517393<br>Latvia
Dial-In #: 80003339<br>Lithuania Dial-In #: 880030479<br>Luxembourg Dial-In
#: 80026595<br>Malaysia Dial-In #: 1800814451<br>Mexico Dial-In #: 00186645
90915<br>New Zealand Dial-In #: 0800888167<br>Norway Dial-In #:
80012994<br>
Panama Dial-In #: 008002269184<br>Philippines Dial-In #: 180011100991<br>Pol
and Dial-In #: 008001210187<br>Portugal Dial-In #: 800814625<br>Russian Fede
ration Dial-In #: 81080028341012<br>Saint Kitts and Nevis Dial-In #: 1800205
9252<br>Singapore Dial-In #: 8006162235<br>Slovak Republic Dial-In #: 080000
1441<br>South Africa Dial-In #: 0800981148<br>Spain Dial-In #:
800300524<br>
Sweden Dial-In #: 200896860<br>Switzerland Dial-In #: 800650077<br>Taiwan Di
al-In #: 00801127141<br>Thailand Dial-In #: 001800656966<br>Trinidad and Tob
ago Dial-In #: 18002024615<br>United Arab Emirates Dial-In #: 8000650591<br>
United Kingdom Dial-In #: 08006948057<br>United States Dial-In #: 8004518679
<br>Uruguay Dial-In #: 00040190315<br>Venezuela Dial-In #:
08001627182</body
</html>
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT30M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
--=_3b1fbb3e-f4ad-474a-8ab2-bf0931975a42--
7:38 a.m.
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?
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).
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?
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?
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.)?
6. STEP table, start_time is "not null" - shouldn't it be nullable?
7. UX - no main tasks view?
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.
9. REST API modeling?
10:02 a.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...
5:53 p.m.
On 01/02/2012 02:02 AM, Moti Asayag wrote:
...
>
> 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).
I think SPM election/status is an interesting enough task that if it
happens it should be documented (as well as its process/results).
>
>
> 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.
oh - I thought a job is pre-defined with its steps, then the backend
runs them.
from your reply i understand the job/steps are just documentation of
what already happened?
6:12 p.m.
On 01/02/2012 09:53 AM, Itamar Heim wrote:
On 01/02/2012 02:02 AM, Moti Asayag wrote:
...
>>
>> 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).
I think SPM election/status is an interesting enough task that if it
happens it should be documented (as well as its process/results).
>
>>
>>
>> 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.
oh - I thought a job is pre-defined with its steps, then the backend
runs them.
from your reply i understand the job/steps are just documentation of
what already happened?
Correct. The Command implementation will determine by code
when to add a
step and how to decide it ended. A default implementation is provided
for all commands, except those which specified on the requirements to be
more detailed.
Doing the other way (let the flow definition execute the steps) means
implementing a business process manager (or using existing one - such as
jBPM). I don't think the backend as implemented now is capable of
adjusting to it and letting external service orchestrate the flow.
7:05 p.m.
On 01/02/2012 10:12 AM, Moti Asayag wrote:
On 01/02/2012 09:53 AM, Itamar Heim wrote:
> On 01/02/2012 02:02 AM, Moti Asayag wrote:
> ...
>
>>>
>>> 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).
>
> I think SPM election/status is an interesting enough task that if it
> happens it should be documented (as well as its process/results).
>
>>
>>>
>>>
>>> 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.
>
> oh - I thought a job is pre-defined with its steps, then the backend
> runs them.
> from your reply i understand the job/steps are just documentation of
> what already happened?
Actually, also of what is already happening, If I
understand correctly.
Correct. The Command implementation will determine by code when to
add a
step and how to decide it ended. A default implementation is provided
for all commands, except those which specified on the requirements to be
more detailed.
Doing the other way (let the flow definition execute the steps) means
implementing a business process manager (or using existing one - such as
jBPM). I don't think the backend as implemented now is capable of
adjusting to it and letting external service orchestrate the flow.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:16 p.m.
On 01/02/2012 11:05 AM, Yair Zaslavsky wrote:
On 01/02/2012 10:12 AM, Moti Asayag wrote:
> On 01/02/2012 09:53 AM, Itamar Heim wrote:
>> On 01/02/2012 02:02 AM, Moti Asayag wrote:
>> ...
>>
>>>>
>>>> 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).
>>
>> I think SPM election/status is an interesting enough task that if it
>> happens it should be documented (as well as its process/results).
>>
>>>
>>>>
>>>>
>>>> 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.
>>
>> oh - I thought a job is pre-defined with its steps, then the backend
>> runs them.
>> from your reply i understand the job/steps are just documentation of
>> what already happened?
Actually, also of what is already happening, If I understand correctly.
Correct.
See
http://ovirt.org/wiki/Features/TaskManagerDetailed#Simple_Command_Invocat...
> Correct. The Command implementation will determine by code when to add a
> step and how to decide it ended. A default implementation is provided
> for all commands, except those which specified on the requirements to be
> more detailed.
>
> Doing the other way (let the flow definition execute the steps) means
> implementing a business process manager (or using existing one - such as
> jBPM). I don't think the backend as implemented now is capable of
> adjusting to it and letting external service orchestrate the flow.
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:34 p.m.
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?
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.
Would not it be better to declare correlation_id and external_id as UUID
instead of String.
Does the task name is calculated on create, or should it be persisted in
the DB?
Besides that, looks very good!
Regards,
Maor Lipchuk
9:38 p.m.
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?
I think we should still have a "safe-way" mechanism for the issue of
tasks that are not ended properly.
What should be the behaviour when user will try to end step deleteVolume
from the GUI? How will it reflect the entire Job?
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.
We should carefully consider DB performance over
readability/debugging
of DB. For example, JPA lets you define if the enum maps as string or
int to DB, and there is a reason why they let you choose :)
Would not it be better to declare correlation_id and external_id as
UUID
instead of String.
+1
Does the task name is calculated on create, or should it be persisted in
the DB?
Besides that, looks very good!
Regards,
Maor Lipchuk
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:05 p.m.
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
1:02 a.m.
Original Message -----
On 01/02/2012 11:05 AM, Yair Zaslavsky wrote:
> On 01/02/2012 10:12 AM, Moti Asayag wrote:
>> On 01/02/2012 09:53 AM, Itamar Heim wrote:
>>> On 01/02/2012 02:02 AM, Moti Asayag wrote:
>>> ...
>>>
>>>>>
>>>>> 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).
>>>
>>> I think SPM election/status is an interesting enough task that if
>>> it
>>> happens it should be documented (as well as its process/results).
>>>
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>
>>> oh - I thought a job is pre-defined with its steps, then the
>>> backend
>>> runs them.
>>> from your reply i understand the job/steps are just documentation
>>> of
>>> what already happened?
> Actually, also of what is already happening, If I understand
> correctly.
Correct.
See
http://ovirt.org/wiki/Features/TaskManagerDetailed#Simple_Command_Invocat...
I think, as I said in the design review meeting, that having each job be broken down to
2-3 steps of: validation, execution, finalization is too verbose for the user of the UI.
I believe this can all be encapsulated in a status field for the job.
Of course, steps which represent a "child job" invocation are still logically
perfect - the parent job will be in state "executing" and the child job will
have it's own representation with the correct state.
>
>> Correct. The Command implementation will determine by code when to
>> add a
>> step and how to decide it ended. A default implementation is
>> provided
>> for all commands, except those which specified on the requirements
>> to be
>> more detailed.
>>
>> Doing the other way (let the flow definition execute the steps)
>> means
>> implementing a business process manager (or using existing one -
>> such as
>> jBPM). I don't think the backend as implemented now is capable of
>> adjusting to it and letting external service orchestrate the flow.
>>
Regards,
Mike
2:25 a.m.
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, January 2, 2012 5:02:22 PM
Subject: Re: [Engine-devel] Task Manager Design Review
Original Message -----
> On 01/02/2012 11:05 AM, Yair Zaslavsky wrote:
> > On 01/02/2012 10:12 AM, Moti Asayag wrote:
> >> On 01/02/2012 09:53 AM, Itamar Heim wrote:
> >>> On 01/02/2012 02:02 AM, Moti Asayag wrote:
> >>> ...
> >>>
> >>>>>
> >>>>> 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).
> >>>
> >>> I think SPM election/status is an interesting enough task that
> >>> if
> >>> it
> >>> happens it should be documented (as well as its
> >>> process/results).
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>> 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.
> >>>
> >>> oh - I thought a job is pre-defined with its steps, then the
> >>> backend
> >>> runs them.
> >>> from your reply i understand the job/steps are just
> >>> documentation
> >>> of
> >>> what already happened?
> > Actually, also of what is already happening, If I understand
> > correctly.
> Correct.
> See
>
http://ovirt.org/wiki/Features/TaskManagerDetailed#Simple_Command_Invocat...
>
I think, as I said in the design review meeting, that having each job
be broken down to 2-3 steps of: validation, execution, finalization
is too verbose for the user of the UI.
I believe this can all be encapsulated in a status field for the job.
Of course, steps which represent a "child job" invocation are still
logically perfect - the parent job will be in state "executing" and
the child job will have it's own representation with the correct
state.
i like this one less, because some of the state will be in steps and some in status,
it is more confusing for the user and for the developer
(for example while implementing a new command, a question may rise if the next call should
be step or status),
and i don't think it adds anything.
> >
> >> Correct. The Command implementation will determine by code when
> >> to
> >> add a
> >> step and how to decide it ended. A default implementation is
> >> provided
> >> for all commands, except those which specified on the
> >> requirements
> >> to be
> >> more detailed.
> >>
> >> Doing the other way (let the flow definition execute the steps)
> >> means
> >> implementing a business process manager (or using existing one -
> >> such as
> >> jBPM). I don't think the backend as implemented now is capable
> >> of
> >> adjusting to it and letting external service orchestrate the
> >> flow.
> >>
>
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:58 a.m.
On 01/02/2012 06:25 PM, Omer Frenkel wrote:
----- Original Message -----
> From: "Mike Kolesnik"<mkolesni(a)redhat.com>
> To: "Moti Asayag"<masayag(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, January 2, 2012 5:02:22 PM
> Subject: Re: [Engine-devel] Task Manager Design Review
>
> Original Message -----
>> On 01/02/2012 11:05 AM, Yair Zaslavsky wrote:
>>> On 01/02/2012 10:12 AM, Moti Asayag wrote:
>>>> On 01/02/2012 09:53 AM, Itamar Heim wrote:
>>>>> On 01/02/2012 02:02 AM, Moti Asayag wrote:
>>>>> ...
>>>>>
>>>>>>>
>>>>>>> 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).
>>>>>
>>>>> I think SPM election/status is an interesting enough task that
>>>>> if
>>>>> it
>>>>> happens it should be documented (as well as its
>>>>> process/results).
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> oh - I thought a job is pre-defined with its steps, then the
>>>>> backend
>>>>> runs them.
>>>>> from your reply i understand the job/steps are just
>>>>> documentation
>>>>> of
>>>>> what already happened?
>>> Actually, also of what is already happening, If I understand
>>> correctly.
>> Correct.
>> See
>>
http://ovirt.org/wiki/Features/TaskManagerDetailed#Simple_Command_Invocat...
>>
>
> I think, as I said in the design review meeting, that having each job
> be broken down to 2-3 steps of: validation, execution, finalization
> is too verbose for the user of the UI.
> I believe this can all be encapsulated in a status field for the job.
>
> Of course, steps which represent a "child job" invocation are still
> logically perfect - the parent job will be in state "executing" and
> the child job will have it's own representation with the correct
> state.
>
i like this one less, because some of the state will be in steps and some in status,
it is more confusing for the user and for the developer
(for example while implementing a new command, a question may rise if the next call
should be step or status),
and i don't think it adds anything.
but every external step may have sub status changes (say, disk creation
progress bar, or delete vs. wipe after delete steps, etc.)
4498
days inactive
4499
days old
12 comments
6 participants
participants (6)
-
Itamar Heim -
Maor -
Mike Kolesnik -
Moti Asayag -
Omer Frenkel -
Yair Zaslavsky