[Engine-devel] API design and plan
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki: http://ovirt.org/wiki/Vdsm_API Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks! -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc. I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command. Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb). A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding. The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion? Dan.
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command.
Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space.
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion?
Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration. So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests. -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote:
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command.
Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space.
Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this process. (CAVE split brain) At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion?
Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests.
Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.) Dan.
----- Original Message -----
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote:
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command.
Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space.
Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion?
Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests.
Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan.
I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc. Requiring an additional xml-rpc server sounds wrong to me.
_______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message -----
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote:
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command.
Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space.
Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion?
Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests.
Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan.
I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
Requiring an additional xml-rpc server sounds wrong to me.
The other option is to support a migrateCreate binding in REST and QMF. -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
I just noticed, why are we cross-posting to engine-devel? Anyway, comments inline ----- Original Message -----
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message -----
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote:
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command.
Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space.
Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion?
Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests.
Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan.
I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
proper migration requires a lot of coordination. e.g. making sure that both source and target have the same networks (required by guest) available, access to shared storage, access to same vm configuration, handling split brain scenarios, etc. This has to be managed somehow... I don't think that ovirt-engine should be a requirement for this, but something should take care of this. This entity could just initiate migrateCreate on destination if not using qmf.
Requiring an additional xml-rpc server sounds wrong to me.
The other option is to support a migrateCreate binding in REST and QMF.
I see no problem with this, I don't view preparing to accept a migration as an internal flow, it can be directed by either another vdsm or a management server or anything else. Seeing as it is by any event run by an external entity, it should be a public API.
-- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 12/08/2011 04:34 PM, Ayal Baron wrote:
I just noticed, why are we cross-posting to engine-devel?
Anyway, comments inline
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message -----
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote:
On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote: > Hi everyone. On today's VDSM call we discussed the > requirements, design, and > plan for updating the API to include support for QMF and > single-host REST API. > All members present arrived at a general consensus on the > best > way to design the > next-generation API. I have tried to capture this > discussion > in the oVirt wiki: > > http://ovirt.org/wiki/Vdsm_API > > Please take a look at this page and let's discuss any > changes > that may be needed > in order to adopt it as a working plan that we can begin to > execute. Thanks! > Very nice, I've fixed two bullets about the future of the xml-rpc. Thanks... Updates look good to me.
I think that we are missing something here: how do we model Vdsm-to-Vdsm communication, in a binding-blind way? I'm less worried about the storage-based mailbox used for lvextend requests: my problem is with migration command. Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space. Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote: process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
Currently, the implementation of the "migrate" verb includes contacting the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 command ('migrationCreate' verb).
A Vdsm user who choose to use the REST binding, is likely to want this to be implemented this using a REST request to the destination. This means that the implementation of Vdsm depends on the chosen binding.
The issue can be mitigating by requiring the binding level to provide a "callback" for migrationCreate (and any other future Vdsm->world requests). This would complicate the beautiful png at http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another suggestion? Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests. Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan. I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
----- Original Message ----- proper migration requires a lot of coordination. e.g. making sure that both source and target have the same networks (required by guest) available, access to shared storage, access to same vm configuration, handling split brain scenarios, etc. This has to be managed somehow... I don't think that ovirt-engine should be a requirement for this, but something should take care of this. This entity could just initiate migrateCreate on destination if not using qmf.
Requiring an additional xml-rpc server sounds wrong to me. The other option is to support a migrateCreate binding in REST and QMF. I see no problem with this, I don't view preparing to accept a migration as an internal flow, it can be directed by either another vdsm or a management server or anything else. Seeing as it is by any event run by an external entity, it should be a public API.
-- Adam Litke<agl@us.ibm.com> IBM Linux Technology Center
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Is there a bias towards using the mailing list and against the discussion tab on the wiki page when discussing wiki pages? Just want to know. I'm used to commenting on wikis on the discussion page.
On 12/12/2011 08:18 PM, Jon Choate wrote:
On 12/08/2011 04:34 PM, Ayal Baron wrote:
I just noticed, why are we cross-posting to engine-devel?
Anyway, comments inline
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message -----
On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote: > On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote: >> Hi everyone. On today's VDSM call we discussed the >> requirements, design, and >> plan for updating the API to include support for QMF and >> single-host REST API. >> All members present arrived at a general consensus on the >> best >> way to design the >> next-generation API. I have tried to capture this >> discussion >> in the oVirt wiki: >> >> http://ovirt.org/wiki/Vdsm_API >> >> Please take a look at this page and let's discuss any >> changes >> that may be needed >> in order to adopt it as a working plan that we can begin to >> execute. Thanks! >> > Very nice, I've fixed two bullets about the future of the > xml-rpc. Thanks... Updates look good to me.
> I think that we are missing something here: how do we model > Vdsm-to-Vdsm > communication, in a binding-blind way? I'm less worried about > the > storage-based mailbox used for lvextend requests: my problem > is > with > migration command. Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space. Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote: process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
> Currently, the implementation of the "migrate" verb includes > contacting > the remote Vdsm over xml-rpc before issuing the libvirt > migrateToURI2 > command ('migrationCreate' verb). > > A Vdsm user who choose to use the REST binding, is likely to > want > this to > be implemented this using a REST request to the destination. > This > means > that the implementation of Vdsm depends on the chosen > binding. > > The issue can be mitigating by requiring the binding level to > provide a > "callback" for migrationCreate (and any other future > Vdsm->world > requests). > This would complicate the beautiful png at > http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have > another > suggestion? Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration.
So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests. Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan. I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
----- Original Message ----- proper migration requires a lot of coordination. e.g. making sure that both source and target have the same networks (required by guest) available, access to shared storage, access to same vm configuration, handling split brain scenarios, etc. This has to be managed somehow... I don't think that ovirt-engine should be a requirement for this, but something should take care of this. This entity could just initiate migrateCreate on destination if not using qmf.
Requiring an additional xml-rpc server sounds wrong to me. The other option is to support a migrateCreate binding in REST and QMF. I see no problem with this, I don't view preparing to accept a migration as an internal flow, it can be directed by either another vdsm or a management server or anything else. Seeing as it is by any event run by an external entity, it should be a public API.
-- Adam Litke<agl@us.ibm.com> IBM Linux Technology Center
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Is there a bias towards using the mailing list and against the discussion tab on the wiki page when discussing wiki pages? Just want to know. I'm used to commenting on wikis on the discussion page.
mailing list - shouldn't be. wiki - may be lost on the larger audience - I think discussing on the mailing list makes more sense since many don't subscribe to the wiki pages after their first review from when it was published.
----- Original Message -----
On 12/12/2011 08:18 PM, Jon Choate wrote:
On 12/08/2011 04:34 PM, Ayal Baron wrote:
I just noticed, why are we cross-posting to engine-devel?
Anyway, comments inline
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message -----
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote: > On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg > wrote: >> On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote: >>> Hi everyone. On today's VDSM call we discussed the >>> requirements, design, and >>> plan for updating the API to include support for QMF and >>> single-host REST API. >>> All members present arrived at a general consensus on the >>> best >>> way to design the >>> next-generation API. I have tried to capture this >>> discussion >>> in the oVirt wiki: >>> >>> http://ovirt.org/wiki/Vdsm_API >>> >>> Please take a look at this page and let's discuss any >>> changes >>> that may be needed >>> in order to adopt it as a working plan that we can begin to >>> execute. Thanks! >>> >> Very nice, I've fixed two bullets about the future of the >> xml-rpc. > Thanks... Updates look good to me. > >> I think that we are missing something here: how do we model >> Vdsm-to-Vdsm >> communication, in a binding-blind way? I'm less worried about >> the >> storage-based mailbox used for lvextend requests: my problem >> is >> with >> migration command. > Ok, interesting... Besides migration, are there other features > (current or > planned) that would involve P2P communication? I want to > ensure we > consider the > full problem space. Well, I can imagine we would like a host in distress to migrate VMs to whomever can take them, without central management driving this process. (CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by QMF events. Ayal?
>> Currently, the implementation of the "migrate" verb includes >> contacting >> the remote Vdsm over xml-rpc before issuing the libvirt >> migrateToURI2 >> command ('migrationCreate' verb). >> >> A Vdsm user who choose to use the REST binding, is likely to >> want >> this to >> be implemented this using a REST request to the destination. >> This >> means >> that the implementation of Vdsm depends on the chosen >> binding. >> >> The issue can be mitigating by requiring the binding level to >> provide a >> "callback" for migrationCreate (and any other future >> Vdsm->world >> requests). >> This would complicate the beautiful png at >> http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have >> another >> suggestion? > Actually, I think you are blending the external API with vdsm > internals. As a > management server or ovirt-engine, I don't care about the > protocol > that vdsm > uses to contact the migration recipient. As far as I am > concerned > this is a > special case internal function call. For that purpose, I think > xmlrpc is > perfectly well-suited to the task and should be used > unconditionally, regardless > of the bindings used to initiate the migration. > > So I would propose that we modify the design such that we keep > an > extremely thin > xmlrpc server active whose sole purpose is to service internal > P2P > requests. Interesting. We could avoid even that, if we could register a callback with libvirt, so that destination libvirtd called destination Vdsm to verify that all storage and networking resources are ready, before executing qemu. DanPB, can something like that be done? (I guess it is not realistic since we may need to pass vdsm-specific data from source to dest, and libvirt is not supposed to be a general purpose transport.)
Dan. I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
----- Original Message ----- proper migration requires a lot of coordination. e.g. making sure that both source and target have the same networks (required by guest) available, access to shared storage, access to same vm configuration, handling split brain scenarios, etc. This has to be managed somehow... I don't think that ovirt-engine should be a requirement for this, but something should take care of this. This entity could just initiate migrateCreate on destination if not using qmf.
Requiring an additional xml-rpc server sounds wrong to me. The other option is to support a migrateCreate binding in REST and QMF. I see no problem with this, I don't view preparing to accept a migration as an internal flow, it can be directed by either another vdsm or a management server or anything else. Seeing as it is by any event run by an external entity, it should be a public API.
-- Adam Litke<agl@us.ibm.com> IBM Linux Technology Center
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Is there a bias towards using the mailing list and against the discussion tab on the wiki page when discussing wiki pages? Just want to know. I'm used to commenting on wikis on the discussion page.
mailing list - shouldn't be. wiki - may be lost on the larger audience - I think discussing on the mailing list makes more sense since many don't subscribe to the wiki pages after their first review from when it was published.
No offense, but the only thing which is more broken than email for discussing such things is a wiki discussion (mailing list at least pushes changes by default. has clients to manage replies by threads, responses can be sent concurrently etc).
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org, "Jon Choate" <jchoate@redhat.com> Sent: Monday, December 12, 2011 4:40:37 PM Subject: Re: [Engine-devel] API design and plan
----- Original Message -----
On 12/12/2011 08:18 PM, Jon Choate wrote:
On 12/08/2011 04:34 PM, Ayal Baron wrote:
I just noticed, why are we cross-posting to engine-devel?
Anyway, comments inline
On Thu, Dec 08, 2011 at 04:56:17AM -0500, Ayal Baron wrote:
----- Original Message ----- > On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote: >> On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg >> wrote: >>> On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote: >>>> Hi everyone. On today's VDSM call we discussed the >>>> requirements, design, and >>>> plan for updating the API to include support for QMF and >>>> single-host REST API. >>>> All members present arrived at a general consensus on the >>>> best >>>> way to design the >>>> next-generation API. I have tried to capture this >>>> discussion >>>> in the oVirt wiki: >>>> >>>> http://ovirt.org/wiki/Vdsm_API >>>> >>>> Please take a look at this page and let's discuss any >>>> changes >>>> that may be needed >>>> in order to adopt it as a working plan that we can begin >>>> to >>>> execute. Thanks! >>>> >>> Very nice, I've fixed two bullets about the future of the >>> xml-rpc. >> Thanks... Updates look good to me. >> >>> I think that we are missing something here: how do we model >>> Vdsm-to-Vdsm >>> communication, in a binding-blind way? I'm less worried >>> about >>> the >>> storage-based mailbox used for lvextend requests: my >>> problem >>> is >>> with >>> migration command. >> Ok, interesting... Besides migration, are there other >> features >> (current or >> planned) that would involve P2P communication? I want to >> ensure we >> consider the >> full problem space. > Well, I can imagine we would like a host in distress to > migrate > VMs > to > whomever can take them, without central management driving > this > process. > (CAVE split brain) > > At the momemt I cannot think of something that cannot be > implemented > by > QMF events. Ayal? > >>> Currently, the implementation of the "migrate" verb >>> includes >>> contacting >>> the remote Vdsm over xml-rpc before issuing the libvirt >>> migrateToURI2 >>> command ('migrationCreate' verb). >>> >>> A Vdsm user who choose to use the REST binding, is likely >>> to >>> want >>> this to >>> be implemented this using a REST request to the >>> destination. >>> This >>> means >>> that the implementation of Vdsm depends on the chosen >>> binding. >>> >>> The issue can be mitigating by requiring the binding level >>> to >>> provide a >>> "callback" for migrationCreate (and any other future >>> Vdsm->world >>> requests). >>> This would complicate the beautiful png at >>> http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have >>> another >>> suggestion? >> Actually, I think you are blending the external API with >> vdsm >> internals. As a >> management server or ovirt-engine, I don't care about the >> protocol >> that vdsm >> uses to contact the migration recipient. As far as I am >> concerned >> this is a >> special case internal function call. For that purpose, I >> think >> xmlrpc is >> perfectly well-suited to the task and should be used >> unconditionally, regardless >> of the bindings used to initiate the migration. >> >> So I would propose that we modify the design such that we >> keep >> an >> extremely thin >> xmlrpc server active whose sole purpose is to service >> internal >> P2P >> requests. > Interesting. We could avoid even that, if we could register a > callback > with libvirt, so that destination libvirtd called destination > Vdsm to > verify that all storage and networking resources are ready, > before > executing qemu. DanPB, can something like that be done? (I > guess > it > is > not realistic since we may need to pass vdsm-specific data > from > source > to dest, and libvirt is not supposed to be a general purpose > transport.) > > Dan. I don't understand the issue. The whole point of the REST API is to be an easily consumable *single* node management API. Once you start coordinating among different nodes then you need clustering and management (either distributed or centralized), in both cases it is fine to require having a bus in which case you have your method of communications between hosts to replace current xml-rpc.
Implicit in this statement is an assertion that live migration between two vdsm instances will not be supported without orchestration from an ovirt-engine instance. I don't agree with placing such a limitation on vdsm since p2p migration is already well-supported by the underlying components (libvirt and qemu).
----- Original Message ----- proper migration requires a lot of coordination. e.g. making sure that both source and target have the same networks (required by guest) available, access to shared storage, access to same vm configuration, handling split brain scenarios, etc. This has to be managed somehow... I don't think that ovirt-engine should be a requirement for this, but something should take care of this. This entity could just initiate migrateCreate on destination if not using qmf.
Requiring an additional xml-rpc server sounds wrong to me. The other option is to support a migrateCreate binding in REST and QMF. I see no problem with this, I don't view preparing to accept a migration as an internal flow, it can be directed by either another vdsm or a management server or anything else. Seeing as it is by any event run by an external entity, it should be a public API.
-- Adam Litke<agl@us.ibm.com> IBM Linux Technology Center
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Is there a bias towards using the mailing list and against the discussion tab on the wiki page when discussing wiki pages? Just want to know. I'm used to commenting on wikis on the discussion page.
mailing list - shouldn't be. wiki - may be lost on the larger audience - I think discussing on the mailing list makes more sense since many don't subscribe to the wiki pages after their first review from when it was published.
No offense, but the only thing which is more broken than email for discussing such things is a wiki discussion (mailing list at least pushes changes by default. has clients to manage replies by threads, responses can be sent concurrently etc).
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
No offense taken, different tools work better for different groups of people. If we do not want to use the discussion tabs, is there a way to get rid of them so we don't have people posting comments there?
On 12/13/2011 03:02 PM, Jon Choate wrote: ...
No offense taken, different tools work better for different groups of people. If we do not want to use the discussion tabs, is there a way to get rid of them so we don't have people posting comments there?
moved the discussion to infra list for this
On 12/05/2011 07:34 PM, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
as you are going to plan an api... This piece by Geert Jansen summarizes lessons learned from the RHEV-M (ovirt) REST API project https://fedorahosted.org/pipermail/rhevm-api/2011-August/002714.html
On Thu, Dec 08, 2011 at 06:48:53AM +0200, Itamar Heim wrote:
On 12/05/2011 07:34 PM, Adam Litke wrote:
Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks!
as you are going to plan an api... This piece by Geert Jansen summarizes lessons learned from the RHEV-M (ovirt) REST API project https://fedorahosted.org/pipermail/rhevm-api/2011-August/002714.html
Thanks for the link! This is proving to be a very insightful read. I am finding that I have come to many of these same conclusions in my own way as I have been desigining the API (especially regarding the use of JSON over XML). -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
participants (5)
-
Adam Litke -
Ayal Baron -
Dan Kenigsberg -
Itamar Heim -
Jon Choate