Re: [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
-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]
(I cleaned thread a little.)
The following design and it is implementation http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler and especially in
the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC REFERENCE.
2. Readability and robust of code: the code which is written as cyclic
references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over whole project
because of
series of async commands, for me it is a private case?
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
From: Michael Kublin mkub...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eduardo Warszawski ewars...@redhat.com, Liron Aravot
lara...@redhat.com, Maor Lipchuk
mlipc...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Sunday, September 23, 2012 12:41:05 PM
Subject: Re: [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
-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]
(I cleaned thread a little.)
The following design and it is implementation
http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler and
especially in the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC
REFERENCE.
2. Readability and robust of code: the code which is written as
cyclic references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over whole
project because of
series of async commands, for me it is a private case?
This will occur all over the storage commands (which are the only usages of
tasks nowadys).
Moreover, async task handling is done at the Commandbase level (see the end*
methods) - instead of hacking it in X different places whenever we need it, I'd
prefer doing it once, properly.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
- Original Message -
From: Michael Kublin mkub...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eduardo Warszawski ewars...@redhat.com, Liron Aravot
lara...@redhat.com, Maor Lipchuk
mlipc...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Sunday, September 23, 2012 12:41:05 PM
Subject: Re: [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
-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]
(I cleaned thread a little.)
The following design and it is implementation
http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler and
especially in the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC
REFERENCE.
2. Readability and robust of code: the code which is written as
cyclic references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over whole
project because of
series of async commands, for me it is a private case?
What is the private case here exactly?
Every task can have multiple jobs. We've identified several such places (e.g.
live storage migration, move disk, move vm) and I have no doubt more will popup.
As Allon notes below, task handling is done at CommandBase, if you think task
management should be for storage only, you're welcome to push it down to
StorageHandlingCommandBase (or get rid of inheritance here altogether).
This will occur all over the storage commands (which are the only
usages of tasks nowadys).
Moreover, async task handling is done at the Commandbase level (see
the end* methods) - instead of hacking it in X different places
whenever we need it, I'd prefer doing it once, properly.
___
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] RFE: Netwrok Main Tab
1. What actions do you suggest to add? 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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
- Original Message -
From: Ayal Baron aba...@redhat.com
To: Allon Mureinik amure...@redhat.com, Michael Kublin
mkub...@redhat.com
Cc: Liron Aravot lara...@redhat.com, engine-devel
engine-devel@ovirt.org, Eduardo Warszawski
ewars...@redhat.com
Sent: Sunday, September 23, 2012 1:10:07 PM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
- Original Message -
From: Michael Kublin mkub...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eduardo Warszawski ewars...@redhat.com, Liron Aravot
lara...@redhat.com, Maor Lipchuk
mlipc...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Sunday, September 23, 2012 12:41:05 PM
Subject: Re: [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
-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]
(I cleaned thread a little.)
The following design and it is implementation
http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler and
especially in the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC
REFERENCE.
2. Readability and robust of code: the code which is written as
cyclic references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over whole
project because of
series of async commands, for me it is a private case?
What is the private case here exactly?
Every task can have multiple jobs. We've identified several such
places (e.g. live storage migration, move disk, move vm) and I have
no doubt more will popup.
As Allon notes below, task handling is done at CommandBase, if you
think task management should be for storage only, you're welcome to
push it down to StorageHandlingCommandBase (or get rid of
inheritance here altogether).
Interesting , regards cyclic reference no response, but who cares,
it is difficult to answer , that's why better not to response?
Regards private case:
1. We have command that not creating any task
2. We have command that will create a one task.
3. And we have 3 commands meanwhile which will create more than one task.
I think that 3 is private case and not common? (In the future, I removed too
many
lines of code that were preparation for future that never come)
The handling done at CommandBase it means that it is influence all system.
Now regards architecture why I need some handler which will be inside a command
and will call for command methods? Please explain.
This will occur all over the storage commands (which are the only
usages of tasks nowadys).
Moreover, async task handling is done at the Commandbase level (see
the end* methods) - instead of hacking it in X different places
whenever we need it, I'd prefer doing it once, properly.
___
Re: [Engine-devel] RFE: Netwrok Main Tab
- Original Message - From: Alona Kaplan alkap...@redhat.com To: Avi Tal a...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 1:31:32 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. What actions do you suggest to add? Add, Edit and remove actions of each component. 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? No. Just Thinking of a nice display which will present logical network and his connected host/vm configuration instead of passing through dub-tabs I should give it a deeper thought. - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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] RFE: Netwrok Main Tab
- Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 4:17:26 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab - Original Message - From: Alona Kaplan alkap...@redhat.com To: Avi Tal a...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 1:31:32 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. What actions do you suggest to add? Add, Edit and remove actions of each component. Host: Add- What will add action on Networks-Hosts sub tab do? Choose an existing host and attach the network to one of its nics? How will it work? after choosing the host you will open setupNetworks window and just enable dragging of the selected network (in the main tab) to a nic? I think it is too much. Edit- same as add. Remove- What is the meaning of Remove host in network's context? The network will be detached from the host? I think it is confusing. Vm/Template: Add: What will it do? You will choose a vm and then add a vnic to the vm? Where will you see the vnic details? Edit: Same as add. Remove: You will remove all the vnics that use the selected network from the vm? Or do you mean to add a remove per vnic? 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? No. Just Thinking of a nice display which will present logical network and his connected host/vm configuration instead of passing through dub-tabs I should give it a deeper thought. - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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] RFE: Netwrok Main Tab
On 09/23/2012 04:55 PM, Alona Kaplan wrote: - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 4:17:26 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab - Original Message - From: Alona Kaplan alkap...@redhat.com To: Avi Tal a...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 1:31:32 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. What actions do you suggest to add? Add, Edit and remove actions of each component. Host: Add- What will add action on Networks-Hosts sub tab do? Choose an existing host and attach the network to one of its nics? How will it work? after choosing the host you will open setupNetworks window and just enable dragging of the selected network (in the main tab) to a nic? I think it is too much. Edit- same as add. Remove- What is the meaning of Remove host in network's context? The network will be detached from the host? I think it is confusing. Vm/Template: Add: What will it do? You will choose a vm and then add a vnic to the vm? Where will you see the vnic details? Edit: Same as add. Remove: You will remove all the vnics that use the selected network from the vm? Or do you mean to add a remove per vnic? For all the above: yes. We can certainly work on the small details, but having a main tab with little to no action whatsoever is kinda disappointing. (example of 'small details' - yes, when clicking remove for a VM/template - it will remove all vNICs that use that network from the VM. A VM with more than one vNIC on the same network is not the common case anyway, and if you want to remove just a single vNIC, go to the VM). I think we can also live with Add/Remove only, and 'defer' the edit actions to the respectable objects (host/vm/template) edit dialog boxes that originates from their own main tab. Y. 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? No. Just Thinking of a nice display which will present logical network and his connected host/vm configuration instead of passing through dub-tabs I should give it a deeper thought. - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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
- Original Message -
- Original Message -
From: Ayal Baron aba...@redhat.com
To: Allon Mureinik amure...@redhat.com, Michael Kublin
mkub...@redhat.com
Cc: Liron Aravot lara...@redhat.com, engine-devel
engine-devel@ovirt.org, Eduardo Warszawski
ewars...@redhat.com
Sent: Sunday, September 23, 2012 1:10:07 PM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
- Original Message -
- Original Message -
From: Michael Kublin mkub...@redhat.com
To: Allon Mureinik amure...@redhat.com
Cc: Eduardo Warszawski ewars...@redhat.com, Liron Aravot
lara...@redhat.com, Maor Lipchuk
mlipc...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Sunday, September 23, 2012 12:41:05 PM
Subject: Re: [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
-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]
(I cleaned thread a little.)
The following design and it is implementation
http://gerrit.ovirt.org/#/c/7956/
is bad.
I don't see any reason for creating a new SPMAsyncTaskHandler
and
especially in the
way as it's done in patch.
The reason are following:
1. Performance , increased memory footprint, created CYCLIC
REFERENCE.
2. Readability and robust of code: the code which is written as
cyclic references is unreadable
and difficult for debug.
3. Why I need a generic implementation and changes all over
whole
project because of
series of async commands, for me it is a private case?
What is the private case here exactly?
Every task can have multiple jobs. We've identified several such
places (e.g. live storage migration, move disk, move vm) and I have
no doubt more will popup.
As Allon notes below, task handling is done at CommandBase, if you
think task management should be for storage only, you're welcome to
push it down to StorageHandlingCommandBase (or get rid of
inheritance here altogether).
Interesting , regards cyclic reference no response, but who cares,
it is difficult to answer , that's why better not to response?
There is no problem with cyclic references in general, GCs know how to deal
with these just fine and in this case it's limited to the command and its
handlers.
I did not reply, however, as I do not feel strongly about this.
Regards private case:
1. We have command that not creating any task
2. We have command that will create a one task.
3. And we have 3 commands meanwhile which will create more than one
task.
I think that 3 is private case and not common? (In the future, I
once happens
twice is a coincidence
three times is a method
But if you insist on more then it's easy enough. We've discussed many times in
the past that we need to change many of the storage verbs to run
Re: [Engine-devel] RFE: Netwrok Main Tab
On 09/23/2012 05:01 PM, Yaniv Kaul wrote: On 09/23/2012 04:55 PM, Alona Kaplan wrote: - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 4:17:26 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab - Original Message - From: Alona Kaplan alkap...@redhat.com To: Avi Tal a...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 1:31:32 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. What actions do you suggest to add? Add, Edit and remove actions of each component. Host: Add- What will add action on Networks-Hosts sub tab do? Choose an existing host and attach the network to one of its nics? How will it work? after choosing the host you will open setupNetworks window and just enable dragging of the selected network (in the main tab) to a nic? I think it is too much. Edit- same as add. Remove- What is the meaning of Remove host in network's context? The network will be detached from the host? I think it is confusing. Vm/Template: Add: What will it do? You will choose a vm and then add a vnic to the vm? Where will you see the vnic details? Edit: Same as add. Remove: You will remove all the vnics that use the selected network from the vm? Or do you mean to add a remove per vnic? For all the above: yes. We can certainly work on the small details, but having a main tab with little to no action whatsoever is kinda disappointing. IMO adding 'assign' action in the main tab might be handy in order to assign a single network in a single dialog to several clusters. However It is not clear to me how Add/Edit for a VM in a sub-tab should look like. The VM should have a list of interfaces (represented as sub collection/tree). What will be the meaning of 'Add' in that context? Since the VM already have a vNIC attached to that network. If adding another once, it should be enabled on the record representing the VM itself which will confuse the user. Same goes for 'Edit' of a VM interface under a context of a specific network: in the current 'Edit VM Interface' you can change the network. Should the same dialog be used here as well? The 'Remove' option is the clearer action on this context. (example of 'small details' - yes, when clicking remove for a VM/template - it will remove all vNICs that use that network from the VM. A VM with more than one vNIC on the same network is not the common case anyway, and if you want to remove just a single vNIC, go to the VM). I think we can also live with Add/Remove only, and 'defer' the edit actions to the respectable objects (host/vm/template) edit dialog boxes that originates from their own main tab. Y. 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? No. Just Thinking of a nice display which will present logical network and his connected host/vm configuration instead of passing through dub-tabs I should give it a deeper thought. - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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] RFE: Netwrok Main Tab
On 09/23/2012 06:12 PM, Moti Asayag wrote: On 09/23/2012 05:01 PM, Yaniv Kaul wrote: On 09/23/2012 04:55 PM, Alona Kaplan wrote: - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 4:17:26 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab - Original Message - From: Alona Kaplan alkap...@redhat.com To: Avi Tal a...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, September 23, 2012 1:31:32 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. What actions do you suggest to add? Add, Edit and remove actions of each component. Host: Add- What will add action on Networks-Hosts sub tab do? Choose an existing host and attach the network to one of its nics? How will it work? after choosing the host you will open setupNetworks window and just enable dragging of the selected network (in the main tab) to a nic? I think it is too much. Edit- same as add. Remove- What is the meaning of Remove host in network's context? The network will be detached from the host? I think it is confusing. Vm/Template: Add: What will it do? You will choose a vm and then add a vnic to the vm? Where will you see the vnic details? Edit: Same as add. Remove: You will remove all the vnics that use the selected network from the vm? Or do you mean to add a remove per vnic? For all the above: yes. We can certainly work on the small details, but having a main tab with little to no action whatsoever is kinda disappointing. IMO adding 'assign' action in the main tab might be handy in order to assign a single network in a single dialog to several clusters. However It is not clear to me how Add/Edit for a VM in a sub-tab should look like. The VM should have a list of interfaces (represented as sub collection/tree). I was thinking more of right-click on the network, selecting 'Add to VM' and then selecting single/mutliple VMs from a dialog with all the VMs (yes, filtered via search). Y. What will be the meaning of 'Add' in that context? Since the VM already have a vNIC attached to that network. If adding another once, it should be enabled on the record representing the VM itself which will confuse the user. Same goes for 'Edit' of a VM interface under a context of a specific network: in the current 'Edit VM Interface' you can change the network. Should the same dialog be used here as well? The 'Remove' option is the clearer action on this context. (example of 'small details' - yes, when clicking remove for a VM/template - it will remove all vNICs that use that network from the VM. A VM with more than one vNIC on the same network is not the common case anyway, and if you want to remove just a single vNIC, go to the VM). I think we can also live with Add/Remove only, and 'defer' the edit actions to the respectable objects (host/vm/template) edit dialog boxes that originates from their own main tab. Y. 2. I don't understand your suggestion. You mean add SetupNetworks to the Networks main tab? No. Just Thinking of a nice display which will present logical network and his connected host/vm configuration instead of passing through dub-tabs I should give it a deeper thought. - Original Message - From: Avi Tal a...@redhat.com To: Alona Kaplan alkap...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 6:58:05 PM Subject: Re: [Engine-devel] RFE: Netwrok Main Tab 1. Why not having Actions for Hosts, Vms and Templates ? I believe we should have those actions instead of making the user browse between 'network - vms - network (sub tab)' just in order to update VM's network. 2. Why having such a big window which most of the time will be empty? How many logical network would be existed in the system? My suggestion is to go for more graphical window which will present: A. logical networks B. Multiple networks with the host configurations at the same window: very important because most of the System admins would like to have a bigger picture of the entire network configuration - Original Message - From: Alona Kaplan alkap...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, September 20, 2012 1:50:15 PM Subject: [Engine-devel] RFE: Netwrok Main Tab Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkMainTab RFE: https://bugzilla.redhat.com/858742 Thanks, Alona. ___ 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
[Engine-devel] Splitting out the oVirt engine installer
Hi All, First time poster here so let me know if this is better directed some where else I have been writing a installer for openstack and as a base for this I've split out the generic parts of your engine-setup utility[1]. In order to do this I've created a generic installer[2] that is basically all of the parts of the oVirt engine installer that I needed for my openstack installer[3] I'd now like to see if there is interest here to use this generic installer for oVirt. I may have stripped out some stuff from the installer that I should have left in, if that is the case I'm open to recreating this repository with anything generic I shouldn't have stripped out so that the original history is maintained. Would anybody here like to look into the work necessary to use this installer in oVirt? For openstack I've made exclusive use of the plugin functionality and I suspect most changes that would be needed for oVirt would be to move a lot of the code into a similar pattern. If you have any questions/comments just let me know, hopefully you will find this useful and other projects could make use of the great work you have done developing this setup utility Thanks, Derek. [1] https://github.com/derekhiggins/ovirt-engine/tree/master/packaging/fedora/setup [2] https://github.com/derekhiggins/installer [3] https://github.com/derekhiggins/os-installer ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
