Re: [Engine-devel] proposing Arik Hadas as a maintainer of engine core
On 01/30/2014 10:47 AM, Michal Skrivanek wrote: > Dear engine-core maintainers, > I'd like to propose Arik Hadas as a maintainer of oVirt engine backend > > Since he started with oVirt project in October 2012 he was working in various > areas in engine core, demonstrated his abilities with more than 200 patches > merged to engine master alone. Tons of migration related fixes, refactoring > of legacy code, but also new complex features including complementary patches > in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements > for VM&Template operations) > > Thanks in advance for your response. > > Thanks, > michal > +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposing Liron Aravot as an engine-core maintainer
On 01/26/2014 02:47 PM, Tal Nisan wrote: > Hi core maintainers, > > I would like to propose Liron Aravot as an engine-core maintainer. > > Liron joined the oVirt project on June 2012, and has since contributed > over 170 patches to master (not counting backports to various stable > branches). > > He has been instrumental in implementing oVirt's Backup API for external > providers, and has a been a driving force in improving flows regarding > SPM election and master domain reconstruction, handling OVF backups and > various concurrency issues both as a coder and a reviewer. > > Your response would be appreciated. > > Thanks, > Tal. > > +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] build a single maven project with make
Nice one On 07/03/2013 03:02 PM, Roy Golan wrote: > For those of us of dream of clean install a single project like maven > please note that > mvn has a flag which enables you to build a specific artifact even if > your not at that directory > > mvn -pl groupID:artifactId > > so say you modified a single class in vdsbroker do this: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker"/ > > note: the usage of DEV_EXTRA_BUILD_FLAGS and EXTRA_BUILD_FLAGS is not a > mistake. the "clean" target uses EXTRA_BUILD_FLAGS - please review > http://gerrit.ovirt.org/16395 to rectify that. > > now make the ear: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear"/ > > > now your updated artifact is in place. > > Thanks, > Roy > > > ___ > 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
Re: [Engine-devel] about IntelliJ
Hi, can u be more specific? what exactly is not explicit? Regards, Maor On 05/29/2013 01:48 PM, wlbleaboy@126 wrote: > Hi, all: > > Is there anyone used Intellij to build and deploy ovirt-engine > > http://www.ovirt.org/Building_Ovirt_Engine/IDE#IntelliJ is not explicit, > > > > > > > > > > ___ > 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
Re: [Engine-devel] Disk BE very small refactoring
I think the main problem is that we abuse the business entity to act as an O/R mapping class to the DB and also to be used as a business entity for presentation purposes. I understand how Yair thought isPlugged could be fetched from vmDevice, this is a confusing design, and it is just one example and more to come. I suggest that if we already thinking of changing the class hierarchy, we can start by implementing a package for presentation classes for transient classes such as this instead enforcing complex hierarchy. The query class will fetch all the data from the DB and initialized the transient class and send it to the client. I think it could be a good start and will solve many issues we might encounter in the future. Regards, Maor On 05/28/2013 11:24 AM, Omer Frenkel wrote: > > > - Original Message - >> From: "Yair Zaslavsky" >> To: "Vered Volansky" >> Cc: engine-devel@ovirt.org >> Sent: Monday, May 27, 2013 6:22:58 PM >> Subject: Re: [Engine-devel] Disk BE very small refactoring >> >> Vered, >> VmDevice has "isPlugged" field, >> Why not have somehow in your inheritence (either Disk or a subclass) a field >> : "VmDevice device" > > disk id is the device id, no need for field to represent the relation. > the combination of disk-id and a specific entity (vm/template) will get you > the other info > >> and have isPlugged method called "device.isPlugged()" ? >> >> Then you can also add the readOnly property which is not represented at >> VmDevice. >> >> >> Does this sound logical to you? >> >> - Original Message - >>> From: "Vered Volansky" >>> To: engine-devel@ovirt.org >>> Sent: Monday, May 27, 2013 6:18:58 PM >>> Subject: [Engine-devel] Disk BE very small refactoring >>> >>> Hi All, >>> >>> Please express your opinion if you have any - >>> >>> Currently Disk BE has a plugged property, which should be a property of the >>> relationship between vm(or template) and a disk. >>> I plan to remove this property from the Disk entity, and add new entity, >>> called DeviceDisk. >>> This should inherit from Disk and contain the vm/template guid and the >>> plugged property at first round. >>> At second round it'll also contain the readOnly property, for RO disks, TBD >>> right after. >>> >>> Appreciate any input, >>> Vered >>> ___ >>> 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 >> > ___ > 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
Re: [Engine-devel] Changing Gerrit -1 message
I tend to agree as well regarding the -1 message, although I think that since -2 blocks your change from, merging it, it should still be strict. Perhaps we could consider adding one more negative value? Regards, Maor On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote: > I like most of these proposals. It'll make gerrit friendlier :-) > > - Original Message - >> From: "Itamar Heim" >> To: "Laszlo Hornyak" >> Cc: engine-devel@ovirt.org >> Sent: Wednesday, February 20, 2013 9:32:53 AM >> Subject: Re: [Engine-devel] Changing Gerrit -1 message >> >> On 19/02/2013 12:06, Laszlo Hornyak wrote: >>> Hi, >>> >>> I agree with that. >>> >>> for the - messages this in my opinion would be both more clear and >>> friendly: >>> -1: In my opinion it needs work. >> >> >> how about >> "-1: Please review my comments" >> >>> -2: I disagree. >> >> "-2: Please reconsider" >> >>> >>> - Original Message - From: "Ofer Schreiber" To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 10:51:15 AM Subject: [Engine-devel] Changing Gerrit -1 message I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself. Any thoughts about a more suitable "-1" message? I thought about "-1 Please fix your code" or something similar. Thanks, Ofer Schreiber ___ 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 >>> >> >> ___ >> 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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core
+1 On 11/14/2012 06:12 AM, Itamar Heim wrote: > Allon has worked on oVirt for the past 10 months. > With 534 patches ranging from cleanups, to complex features like user > level api and storage live migration. In addition, Allon has been > instrumental in the number of patch reviews he has done. > > I'd like to propose Allon as a maintainer of engine core. > > Thanks, >Itamar > ___ > 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
Re: [Engine-devel] eclipse juno vs gwt
Hi Laszlo, Why not change the eclipse configuration, that it won't add @override annotation when saving the class (Java - Editor -Save Actions) but instead use warning instead (java - compiler - Errors/Warnings) Regards, Maor On 11/05/2012 07:08 PM, Laszlo Hornyak wrote: > http://youtu.be/XQ0JmfKs21g > > > > - Original Message - >> From: "Christopher Morrissey" >> To: "Laszlo Hornyak" , "engine-devel" >> >> Sent: Friday, November 2, 2012 11:43:23 PM >> Subject: RE: [Engine-devel] eclipse juno vs gwt >> >> Sorry to follow up my own question, but can you give some specific >> cases where this would be a problem? Thanks! >> >> -Chris >> >> >> -Original Message- >> From: Morrissey, Christopher >> Sent: Friday, November 02, 2012 6:41 PM >> To: 'Laszlo Hornyak'; engine-devel >> Subject: RE: [Engine-devel] eclipse juno vs gwt >> >> Hi Laszlo, >> >> I have several methods that define the @Override annotation and >> return something different from the super class. I haven't had any >> problems compiling them in GWT. The return value does extend from >> the return value of the super class, although this is a requirement >> in Java as well so I'm not sure where the difference is. >> >> -Chris >> >> >> -Original Message- >> From: engine-devel-boun...@ovirt.org >> [mailto:engine-devel-boun...@ovirt.org] On Behalf Of Laszlo Hornyak >> Sent: Friday, November 02, 2012 6:19 AM >> To: engine-devel >> Subject: [Engine-devel] eclipse juno vs gwt >> >> Hi, >> >> Just noticed that eclipse juno is adding @Ovewrride annotations to >> methods that are actually overriding something, like in many cases >> clone and equals methods in some of the classes. This is fine for >> the java compiler, but it in some cases the GWT compiler is not >> going to accept this annotation. E.g. if the return type is >> different than the method with same name in the superclass. >> >> Juno is doing this by default without asking, when saving the file. >> So be extra-careful when editing java classes if they are shared >> with GWT >> >> Laszlo >> ___ >> 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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
On 08/22/2012 12:21 PM, Allon Mureinik wrote: > > > - Original Message - >> From: "Maor Lipchuk" >> To: "Itamar Heim" >> Cc: "Allon Mureinik" , "engine-devel" >> , "Eduardo Warszawski" >> , "Yeela Kaplan" , "Federico >> Simoncelli" , "Liron >> Aravot" >> Sent: Thursday, August 16, 2012 8:27:33 PM >> Subject: Re: [Engine-devel] Serial Execution of Async Tasks >> >> On 08/16/2012 06:51 PM, Itamar Heim wrote: >>> On 08/16/2012 03:21 PM, Maor Lipchuk wrote: >>>> On 08/14/2012 05:23 PM, Itamar Heim wrote: >>>>> On 08/14/2012 02:35 PM, Maor Lipchuk wrote: >>>>>> How should we handle the auditLogMessages? >>>>>> Basically when a command ends it print an audit log. >>>>>> >>>>>> When we will start to use multiple tasks I assume user might get >>>>>> a bulk >>>>>> of audit logs which are actually related to the same action >>>>>> (when we >>>>>> fail for example the process will be create and delete). >>>>>> It might be a bit confusing for the user not to know which >>>>>> action is >>>>>> related to the operation >>>>> >>>>> I thought audit log gets written regardless of the transaction, >>>>> so audit >>>>> log appears "as they happen"? >>>> That is correct, >>>> The issue that I was referring to, is that now, with multiple >>>> tasks >>>> execution, we will get many audit logs which related to the same >>>> transaction but each one will be printed at a different time. >>>> >>>> I think that it might be confusing for the user to relate each >>>> audit log >>>> to the operation that was started. >>>> >>>> >>>> For example : >>>> User run an action that executes some tasks of create volumes, >>>> then the engine encounter a problem, and decide to rollback the >>>> operation and delete the volumes, in that case the engine will >>>> execute a >>>> delete task for the volumes, so user might see that delete of the >>>> volume >>>> (for example a snapshot) was initiated. >>>> Since those are asynchronous tasks, audit log will be printed in a >>>> different period of time and a user might not be aware what is the >>>> relation of those specific delete. >>> >>> async doesn't mean we don't print an audit log when we start it, >>> and >>> when we end it. >>> so user would get the starting audit log when the task failed in >>> your >>> example. of course this may happen 2 hours after they started the >>> task. >>> as long as we can correlate the audit log to be part of the same >>> "job", >>> i don't see the issue. >> yes, but if I understood correctly, we don't want to correlate the >> multiple tasks with the execution handler (which AFAIK handle the >> correlation id). > I actually didn't mention this, but I don't see why not. > What's I'd probably like to have is a log with "Correlation ID xyzabc, step > #3 starting/executing/ending" > Does this make any sense? Sound's great to me. >> >> I assume this issue can be addressed in a future phase, >> but maybe it is an issue that might worth to think about. >>> >>>>> >>>>>> >>>>>> Maybe we will need to use the correlation id of the Execution >>>>>> handler as >>>>>> Eli suggested or maybe add new states at CommandActionState? >>>>>> >>>>>> On 08/14/2012 02:10 PM, Allon Mureinik wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Thanks for all your comments! >>>>>>> The correct response for many these points is to update the >>>>>>> wiki. >>>>>>> I'm enclosing here the quick-and-dirty replies just to keep >>>>>>> this >>>>>>> thread alive, and will update the wiki shortly. >>>>>>> >>>>>>> See inline. >>>>>>> >>>>>>> - Original Message - >>>>>>>> From: "Livnat Peer" >>>>>>>> To: "Allon Mureinik" &g
Re: [Engine-devel] Serial Execution of Async Tasks
On 08/16/2012 06:51 PM, Itamar Heim wrote: > On 08/16/2012 03:21 PM, Maor Lipchuk wrote: >> On 08/14/2012 05:23 PM, Itamar Heim wrote: >>> On 08/14/2012 02:35 PM, Maor Lipchuk wrote: >>>> How should we handle the auditLogMessages? >>>> Basically when a command ends it print an audit log. >>>> >>>> When we will start to use multiple tasks I assume user might get a bulk >>>> of audit logs which are actually related to the same action (when we >>>> fail for example the process will be create and delete). >>>> It might be a bit confusing for the user not to know which action is >>>> related to the operation >>> >>> I thought audit log gets written regardless of the transaction, so audit >>> log appears "as they happen"? >> That is correct, >> The issue that I was referring to, is that now, with multiple tasks >> execution, we will get many audit logs which related to the same >> transaction but each one will be printed at a different time. >> >> I think that it might be confusing for the user to relate each audit log >> to the operation that was started. >> >> >> For example : >> User run an action that executes some tasks of create volumes, >> then the engine encounter a problem, and decide to rollback the >> operation and delete the volumes, in that case the engine will execute a >> delete task for the volumes, so user might see that delete of the volume >> (for example a snapshot) was initiated. >> Since those are asynchronous tasks, audit log will be printed in a >> different period of time and a user might not be aware what is the >> relation of those specific delete. > > async doesn't mean we don't print an audit log when we start it, and > when we end it. > so user would get the starting audit log when the task failed in your > example. of course this may happen 2 hours after they started the task. > as long as we can correlate the audit log to be part of the same "job", > i don't see the issue. yes, but if I understood correctly, we don't want to correlate the multiple tasks with the execution handler (which AFAIK handle the correlation id). I assume this issue can be addressed in a future phase, but maybe it is an issue that might worth to think about. > >>> >>>> >>>> Maybe we will need to use the correlation id of the Execution >>>> handler as >>>> Eli suggested or maybe add new states at CommandActionState? >>>> >>>> On 08/14/2012 02:10 PM, Allon Mureinik wrote: >>>>> Hi guys, >>>>> >>>>> Thanks for all your comments! >>>>> The correct response for many these points is to update the wiki. >>>>> I'm enclosing here the quick-and-dirty replies just to keep this >>>>> thread alive, and will update the wiki shortly. >>>>> >>>>> See inline. >>>>> >>>>> - Original Message - >>>>>> From: "Livnat Peer" >>>>>> To: "Allon Mureinik" >>>>>> Cc: "Eli Mesika" , "Liron Aravot" >>>>>> , "Federico Simoncelli" >>>>>> , "engine-devel" , >>>>>> "Eduardo Warszawski" , "Yeela >>>>>> Kaplan" >>>>>> Sent: Sunday, August 12, 2012 9:39:23 AM >>>>>> Subject: Re: [Engine-devel] Serial Execution of Async Tasks >>>>>> >>>>>> On 10/08/12 03:40, Eli Mesika wrote: >>>>>>> >>>>>>> >>>>>>> - Original Message - >>>>>>>> From: "Allon Mureinik" >>>>>>>> To: "engine-devel" >>>>>>>> Cc: "Eduardo Warszawski" , "Yeela Kaplan" >>>>>>>> , "Federico Simoncelli" >>>>>>>> , "Liron Aravot" >>>>>>>> Sent: Thursday, August 9, 2012 6:41:09 PM >>>>>>>> Subject: [Engine-devel] Serial Execution of Async Tasks >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> As you may know the engine currently has the ability to fire an >>>>>>>> SPM >>>>>>>> task, and be asynchronously be "woken-up" when it ends. >>>>>>>> This is great, but we found the for the Live Storage
Re: [Engine-devel] Serial Execution of Async Tasks
On 08/14/2012 05:23 PM, Itamar Heim wrote: > On 08/14/2012 02:35 PM, Maor Lipchuk wrote: >> How should we handle the auditLogMessages? >> Basically when a command ends it print an audit log. >> >> When we will start to use multiple tasks I assume user might get a bulk >> of audit logs which are actually related to the same action (when we >> fail for example the process will be create and delete). >> It might be a bit confusing for the user not to know which action is >> related to the operation > > I thought audit log gets written regardless of the transaction, so audit > log appears "as they happen"? That is correct, The issue that I was referring to, is that now, with multiple tasks execution, we will get many audit logs which related to the same transaction but each one will be printed at a different time. I think that it might be confusing for the user to relate each audit log to the operation that was started. For example : User run an action that executes some tasks of create volumes, then the engine encounter a problem, and decide to rollback the operation and delete the volumes, in that case the engine will execute a delete task for the volumes, so user might see that delete of the volume (for example a snapshot) was initiated. Since those are asynchronous tasks, audit log will be printed in a different period of time and a user might not be aware what is the relation of those specific delete. > >> >> Maybe we will need to use the correlation id of the Execution handler as >> Eli suggested or maybe add new states at CommandActionState? >> >> On 08/14/2012 02:10 PM, Allon Mureinik wrote: >>> Hi guys, >>> >>> Thanks for all your comments! >>> The correct response for many these points is to update the wiki. >>> I'm enclosing here the quick-and-dirty replies just to keep this >>> thread alive, and will update the wiki shortly. >>> >>> See inline. >>> >>> - Original Message - >>>> From: "Livnat Peer" >>>> To: "Allon Mureinik" >>>> Cc: "Eli Mesika" , "Liron Aravot" >>>> , "Federico Simoncelli" >>>> , "engine-devel" , >>>> "Eduardo Warszawski" , "Yeela >>>> Kaplan" >>>> Sent: Sunday, August 12, 2012 9:39:23 AM >>>> Subject: Re: [Engine-devel] Serial Execution of Async Tasks >>>> >>>> On 10/08/12 03:40, Eli Mesika wrote: >>>>> >>>>> >>>>> - Original Message - >>>>>> From: "Allon Mureinik" >>>>>> To: "engine-devel" >>>>>> Cc: "Eduardo Warszawski" , "Yeela Kaplan" >>>>>> , "Federico Simoncelli" >>>>>> , "Liron Aravot" >>>>>> Sent: Thursday, August 9, 2012 6:41:09 PM >>>>>> Subject: [Engine-devel] Serial Execution of Async Tasks >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> As you may know the engine currently has the ability to fire an >>>>>> SPM >>>>>> task, and be asynchronously be "woken-up" when it ends. >>>>>> This is great, but we found the for the Live Storage Migration >>>>>> feature we need something a bit complex - the ability to have a >>>>>> series of async tasks in a single control flow. >>>>>> >>>>>> Here's my initial design for this, your comments and criticism >>>>>> would >>>>>> be welcome: >>>>>> http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design >>>>>> >>>>> >>>>> Apart from the short explanation & flow , since this is a detailed >>>>> design , I would add >>>>> 1) Class diagram >>>>> 2) Flow diagram >>> Good idea, I'll see if I can jimmy something up. >>> >>>>> >>>> >>>> +1, it would help understanding the flow. >>>> >>>> - It looks like you chose not re-use/extend the ExecutionHandler (the >>>> entity used for building the tasks view exposed to the users). >>>> It might be a good idea to keep the separation between the engine >>>> Jobs >>>> and the underlying vdsm tasks, but I want to make sure you are >>>> familiar >>>> with this mechanism and ruled it out with a reason. If this is t
Re: [Engine-devel] Serial Execution of Async Tasks
How should we handle the auditLogMessages?
Basically when a command ends it print an audit log.
When we will start to use multiple tasks I assume user might get a bulk
of audit logs which are actually related to the same action (when we
fail for example the process will be create and delete).
It might be a bit confusing for the user not to know which action is
related to the operation
Maybe we will need to use the correlation id of the Execution handler as
Eli suggested or maybe add new states at CommandActionState?
On 08/14/2012 02:10 PM, Allon Mureinik wrote:
> Hi guys,
>
> Thanks for all your comments!
> The correct response for many these points is to update the wiki.
> I'm enclosing here the quick-and-dirty replies just to keep this thread
> alive, and will update the wiki shortly.
>
> See inline.
>
> - Original Message -
>> From: "Livnat Peer"
>> To: "Allon Mureinik"
>> Cc: "Eli Mesika" , "Liron Aravot" ,
>> "Federico Simoncelli"
>> , "engine-devel" , "Eduardo
>> Warszawski" , "Yeela
>> Kaplan"
>> Sent: Sunday, August 12, 2012 9:39:23 AM
>> Subject: Re: [Engine-devel] Serial Execution of Async Tasks
>>
>> On 10/08/12 03:40, Eli Mesika wrote:
>>>
>>>
>>> - Original Message -
From: "Allon Mureinik"
To: "engine-devel"
Cc: "Eduardo Warszawski" , "Yeela Kaplan"
, "Federico Simoncelli"
, "Liron Aravot"
Sent: Thursday, August 9, 2012 6:41:09 PM
Subject: [Engine-devel] Serial Execution of Async Tasks
Hi guys,
As you may know the engine currently has the ability to fire an
SPM
task, and be asynchronously be "woken-up" when it ends.
This is great, but we found the for the Live Storage Migration
feature we need something a bit complex - the ability to have a
series of async tasks in a single control flow.
Here's my initial design for this, your comments and criticism
would
be welcome:
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
>>>
>>> Apart from the short explanation & flow , since this is a detailed
>>> design , I would add
>>> 1) Class diagram
>>> 2) Flow diagram
> Good idea, I'll see if I can jimmy something up.
>
>>>
>>
>> +1, it would help understanding the flow.
>>
>> - It looks like you chose not re-use/extend the ExecutionHandler (the
>> entity used for building the tasks view exposed to the users).
>> It might be a good idea to keep the separation between the engine
>> Jobs
>> and the underlying vdsm tasks, but I want to make sure you are
>> familiar
>> with this mechanism and ruled it out with a reason. If this is the
>> case
>> please share why you decided not to use it.
> As you said Jobs and Steps are pure engine entities - they can contain no
> VDSM tasks, one VDSM task, or plausibly, in the future, several tasks.
> Even /today/, AsyncTasks and Jobs/Steps are two different kinds of animals -
> I don't see any added value in mixing them together.
>
>>
>>
>> - how does this design survives a jboss restart? Can you please a
>> section in the wiki to explain that.
> Basically, the way as a Command does today - the task is saved with the
> executionIndex, and continues when the command is woken up.
> I'll clarify this point in the wiki.
>
>>
>> -successful execution -
>> * "CommandBase iterates over its SPMAsyncTaskHandlers" - when?
> This is the new suggested format of executeCommand(). I'll clarify this too.
>
>> * If the second task is an HSM command (vs. SPM command), I think you
>> should explain in the design how to handle such flows as well.
> HSM commands do not create AsyncTasks, as they do today - I will clarify this.
>
>> * Why do we need before task? can you give a concrete example of what
>> would you do in such a method.
> Basically, /today/, command look like this:
> executeCommand() {
> doStuffInTheDB();
> runVdsCommand(someCommand);
> }
>
> endSuccessfully() {
> doMoreStuffInTheDB();
> }
>
> endWithFailure() {
> doMoreStuffForFailureInTheDB();
> }
>
> In the new design, the entire doStuffInTheDB() should be moved to a
> breforeTask of the (only) SPMAsyncTaskHandler.
>
>>
>> - I see you added SPMAsyncTaskHandler, any reason not to use
>> SPMAsyncTasK to manage it own life-cycle?
> Conserving today's design - The SPMAsyncTaskHandler is the place to add
> additional, non-SPM, logic around the SPM task execution, like CommandBase
> allows today.
>
>>
>> - In the life-cycle managed by the SPMAsyncTaskHandler there is a
>> step
>> 'createTask - how to create the async task' can you please elaborate
>> what are the options.
> new [any type of async task]
>>
>>
>>
>>
>>
>> Livnat
>>
-Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> ht
Re: [Engine-devel] Shared Raw Disk - Design change
On 03/13/2012 10:16 PM, Itamar Heim wrote: > On 03/13/2012 08:36 PM, Maor Lipchuk wrote: > ... > >>> 1. affected components - isn't vdsm aware of this as well wrt disk lock >>> protection (appears in both urls) >> You right, Backend sends VDSM an indication when ever we create a VM >> whether the disk is shared or not. >> I Added the OVirt Node, as a related component in the dependencies tab >> at the wiki. > > ovirt node isn't the affected component. vdsm is. > ovirt node has vdsm in it, but so does any host running vdsm (i.e., full > blown fedora host). > Changed to VDSM >>> >>> 2. Remove Shared Disk >>> maybe make it clear this is about delete, not detach from this vm? >>> my view - UI should have a clear warning (with checkbox approval) making >>> it clear delete will remove the shared disk from all VMs sharing it. >> I tried to stay consistent with the semantic here, by not mentioning >> delete and remove in the same sentence. >> I changed it to be as follow: >> >> User can remove the shared raw disk entirely from the setup, whether the >> disk is inactive in all the VMs which are attached to it, or all the VMs >> which the disk is attached to, are in status down (or any combination of >> the two). >> When disk will be removed a warning message should display the user the >> following message : >> >> "Removing the shared disk will remove it from all the VMs which are >> associated with it." > > consult einav on phrasing, or assume it will be looked at later on again > i guess. Sure, I think its better the messages phrase will be looked deeply at the patches review process, also to preserve time now to review the design for more crucial issues, and also since its not hard to change it then. Also suggestions for new phrasing are welcome. > >> >>> >>> 3. Copy Shared Disk >>> this is "clone disk"? do we have it for non shared disks? >> I'm not sure I understood completely. >> Move disk for shared disk, will need to have the same functionality as >> regular disk, the only difference is that fir shared disk I check all >> the VMs which the disk is attached to, whether the disk is inactive in >> the running VMs or attached to non active VMs.> > > your reply started with "move disk for...". I'm asking on "Copy Shared > Disk". > do we have a copy disk action? Oh sorry, got confused with move disk since its using the same command. This is a remaining from the old wiki where shared disk was considered to be handled also with Template. Copy disk should not be considered for shared disk, I removed it from the wiki. > > Thanks, >Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Shared Raw Disk - Design change
Thanks for the comments, Please see responds in the message body. On 03/13/2012 04:47 PM, Itamar Heim wrote: > On 03/12/2012 11:01 AM, Maor Lipchuk wrote: >> Hello all, >> >> The shared raw disk feature description has been changed. >> The changes can be found in the following wiki: >> links: >> http://www.ovirt.org/wiki/Features/SharedRawDisk >> http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk > > 1. affected components - isn't vdsm aware of this as well wrt disk lock > protection (appears in both urls) You right, Backend sends VDSM an indication when ever we create a VM whether the disk is shared or not. I Added the OVirt Node, as a related component in the dependencies tab at the wiki. > > 2. Remove Shared Disk > maybe make it clear this is about delete, not detach from this vm? > my view - UI should have a clear warning (with checkbox approval) making > it clear delete will remove the shared disk from all VMs sharing it. I tried to stay consistent with the semantic here, by not mentioning delete and remove in the same sentence. I changed it to be as follow: User can remove the shared raw disk entirely from the setup, whether the disk is inactive in all the VMs which are attached to it, or all the VMs which the disk is attached to, are in status down (or any combination of the two). When disk will be removed a warning message should display the user the following message : "Removing the shared disk will remove it from all the VMs which are associated with it." > > 3. Copy Shared Disk > this is "clone disk"? do we have it for non shared disks? I'm not sure I understood completely. Move disk for shared disk, will need to have the same functionality as regular disk, the only difference is that fir shared disk I check all the VMs which the disk is attached to, whether the disk is inactive in the running VMs or attached to non active VMs.> > 4. Export/Import > the text is copy/paste from template part - should be fixed to say > export in several places. Fixed, although I found only one mention of template there, hope I didn't missed something. > > 5. move disk > s/inactivatee/inactive/ Fixed, thank you. > > Thanks, > Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Shared Raw Disk - Design change
Hello all, The shared raw disk feature description has been changed. The changes can be found in the following wiki: links: http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk http://www.ovirt.org/wiki/Features/SharedRawDisk Please feel free, to share your comments. Regards, Maor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
