[Engine-devel] Task Manager Design Review
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
--=_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@redhat.com> Location: asia-tlv@redhat.com Resources: asia-tlv@redhat.com Time: Monday, January 2, 2012, 2:00:00 PM - 3:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel@ovirt.org; mgoldboi@redhat.com; ykaul@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" <masayag@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@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><br>You 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@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@redhat.com> \n\nLocation: asia-tlv@redhat.com \nResources: asia-tlv@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@ovirt.org\; mgoldboi@redhat.com\; ykaul@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" <\;masayag@redhat.com>\; </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@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 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--
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? 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?
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...
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?
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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_Invocation...
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
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_Invocation...
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
----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: engine-devel@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_Invocation...
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/02/2012 06:25 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Mike Kolesnik"<mkolesni@redhat.com> To: "Moti Asayag"<masayag@redhat.com> Cc: engine-devel@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_Invocation...
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.)
participants (6)
-
Itamar Heim -
Maor -
Mike Kolesnik -
Moti Asayag -
Omer Frenkel -
Yair Zaslavsky