Re: [Engine-devel] Announcing a proof of concept REST API for VDSM
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
https://github.com/aglitke/vdsm-rest/
Today I am releasing a proof of concept implementation of a REST API for vdsm. You can find the code on github. My goal is to eventually replace the current xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to this new API. The major advantages to making this change are: 1) VDSM will gain a structured API that conceptually, structurally, and functionally aligns with the ovirt-engine REST API, 2) this new API can be made public, thus providing an entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip>
ovirt-engine wants to subscribe to asynchronous events. REST APIs do not typically support async events and instead rely on polling of resources. I am investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
Thanks!
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine). 2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
https://github.com/aglitke/vdsm-rest/
Today I am releasing a proof of concept implementation of a REST API for vdsm. You can find the code on github. My goal is to eventually replace the current xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to this new API. The major advantages to making this change are: 1) VDSM will gain a structured API that conceptually, structurally, and functionally aligns with the ovirt-engine REST API, 2) this new API can be made public, thus providing an entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip>
ovirt-engine wants to subscribe to asynchronous events. REST APIs do not typically support async events and instead rely on polling of resources. I am investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
I tend to agree, using a bus like QMF between ovirt-engine and vdsm is an inherantly more scalable network architecture, since it avoids the need to have a direct point-to-point connection between the engine and every single node, instead you can build a resilient grid by stategically deploying QPid brokers. As compared to REST, it is also much better at coping with async events, since you can have a push, rather than pull, model which VDSM just puts events onto the bus as they're generated, to be lazily consumed by any remote nodes when desired. NB, I don't mean to imply that there should not *also* be a REST API for the node level. A REST API has the very compelling property that it is trivially accessible from anything with HTTP client support, which is basically everything in existance today.
2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
If the REST API is well specified, you wouldn't need to necessarily have a lightweight ovirt-engine deployed at the node level, you could just have VDSM implement the same REST specification natively, as is impl in the engine. Or perhaps provide a some shered code that can be plugged into both VDSM & the enegine to facilitate provision of the same REST interface. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 11/30/2011 11:29 AM, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote: > > https://github.com/aglitke/vdsm-rest/ > > Today I am releasing a proof of concept implementation of a REST API for vdsm. > You can find the code on github. My goal is to eventually replace the current > xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to > this new API. The major advantages to making this change are: 1) VDSM will gain > a structured API that conceptually, structurally, and functionally aligns with > the ovirt-engine REST API, 2) this new API can be made public, thus providing an > entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip> > ovirt-engine wants to subscribe to asynchronous events. REST APIs do not > typically support async events and instead rely on polling of resources. I am > investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
I tend to agree, using a bus like QMF between ovirt-engine and vdsm is an inherantly more scalable network architecture, since it avoids the need to have a direct point-to-point connection between the engine and every single node, instead you can build a resilient grid by stategically deploying QPid brokers.
As compared to REST, it is also much better at coping with async events, since you can have a push, rather than pull, model which VDSM just puts events onto the bus as they're generated, to be lazily consumed by any remote nodes when desired.
NB, I don't mean to imply that there should not *also* be a REST API for the node level. A REST API has the very compelling property that it is trivially accessible from anything with HTTP client support, which is basically everything in existance today.
2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
If the REST API is well specified, you wouldn't need to necessarily have a lightweight ovirt-engine deployed at the node level, you could just have VDSM implement the same REST specification natively, as is impl in the engine. Or perhaps provide a some shered code that can be plugged into both VDSM& the enegine to facilitate provision of the same REST interface.
Indeed, but an API is not just the transport, it is also behavior and error code numbering, etc. trying to develop two different projects trying to do the same thing sounds like quite the overhead to me. I prefer investing the time in making a lighter version of the engine for a single node. then you would also get the web admin and power user portal if you want them.
On Wed, Nov 30, 2011 at 03:21:07PM +0200, Itamar Heim wrote:
On 11/30/2011 11:29 AM, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote: >* Adam Litke (agl@us.ibm.com) wrote: >> >>https://github.com/aglitke/vdsm-rest/ >> >>Today I am releasing a proof of concept implementation of a REST API for vdsm. >>You can find the code on github. My goal is to eventually replace the current >>xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to >>this new API. The major advantages to making this change are: 1) VDSM will gain >>a structured API that conceptually, structurally, and functionally aligns with >>the ovirt-engine REST API, 2) this new API can be made public, thus providing an >>entry point for direct virtualization management@the node level. > >Adam, this looks like a nice PoC. I didn't see how API versioning is >handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
><snip> >>ovirt-engine wants to subscribe to asynchronous events. REST APIs do not >>typically support async events and instead rely on polling of resources. I am >>investigating what options are available for supporting async events via REST. > >I think typical is either polling or long polling. If it's a single >resource, then perhaps long polling would be fine (won't be a large >number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
I tend to agree, using a bus like QMF between ovirt-engine and vdsm is an inherantly more scalable network architecture, since it avoids the need to have a direct point-to-point connection between the engine and every single node, instead you can build a resilient grid by stategically deploying QPid brokers.
As compared to REST, it is also much better at coping with async events, since you can have a push, rather than pull, model which VDSM just puts events onto the bus as they're generated, to be lazily consumed by any remote nodes when desired.
NB, I don't mean to imply that there should not *also* be a REST API for the node level. A REST API has the very compelling property that it is trivially accessible from anything with HTTP client support, which is basically everything in existance today.
2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
If the REST API is well specified, you wouldn't need to necessarily have a lightweight ovirt-engine deployed at the node level, you could just have VDSM implement the same REST specification natively, as is impl in the engine. Or perhaps provide a some shered code that can be plugged into both VDSM& the enegine to facilitate provision of the same REST interface.
Indeed, but an API is not just the transport, it is also behavior and error code numbering, etc. trying to develop two different projects trying to do the same thing sounds like quite the overhead to me.
Agreed.
I prefer investing the time in making a lighter version of the engine for a single node. then you would also get the web admin and power user portal if you want them.
Could you flesh out some details on the effort required to implement a light-weight engine? I am concerned that this is more complex than it seems. Also, how would we avoid dual maintenance between the full engine and the light one when a new feature/api is added? -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 11/30/2011 05:15 PM, Adam Litke wrote:
On Wed, Nov 30, 2011 at 03:21:07PM +0200, Itamar Heim wrote:
On 11/30/2011 11:29 AM, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote: > On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote: >> * Adam Litke (agl@us.ibm.com) wrote: >>> >>> https://github.com/aglitke/vdsm-rest/ >>> >>> Today I am releasing a proof of concept implementation of a REST API for vdsm. >>> You can find the code on github. My goal is to eventually replace the current >>> xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to >>> this new API. The major advantages to making this change are: 1) VDSM will gain >>> a structured API that conceptually, structurally, and functionally aligns with >>> the ovirt-engine REST API, 2) this new API can be made public, thus providing an >>> entry point for direct virtualization management@the node level. >> >> Adam, this looks like a nice PoC. I didn't see how API versioning is >> handled. Any VDSM developers willing to review this work? > > Thanks for taking a look. I am not handling versioning yet. I think we can add > a version field to the root API object. As for compatibility, we'll just have > to decide on an API backwards-compat support policy. Would this be enough to > handle versioning issues? We shouldn't need anything like capabilities because > the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
>> <snip> >>> ovirt-engine wants to subscribe to asynchronous events. REST APIs do not >>> typically support async events and instead rely on polling of resources. I am >>> investigating what options are available for supporting async events via REST. >> >> I think typical is either polling or long polling. If it's a single >> resource, then perhaps long polling would be fine (won't be a large >> number of connections tied up if it's only a single resource). > > Not sure if this is what you are referring to, but I was thinking we could do a > batch-polling mechanism where an API user passes in a list of task UUIDs and/or > event URIs. The server would respond with the status of these resources in one > response. I have some ideas on how we could wire up asynchronous events on the > server side to reduce the amount of actual work that such a batch-polling > operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
I tend to agree, using a bus like QMF between ovirt-engine and vdsm is an inherantly more scalable network architecture, since it avoids the need to have a direct point-to-point connection between the engine and every single node, instead you can build a resilient grid by stategically deploying QPid brokers.
As compared to REST, it is also much better at coping with async events, since you can have a push, rather than pull, model which VDSM just puts events onto the bus as they're generated, to be lazily consumed by any remote nodes when desired.
NB, I don't mean to imply that there should not *also* be a REST API for the node level. A REST API has the very compelling property that it is trivially accessible from anything with HTTP client support, which is basically everything in existance today.
2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
If the REST API is well specified, you wouldn't need to necessarily have a lightweight ovirt-engine deployed at the node level, you could just have VDSM implement the same REST specification natively, as is impl in the engine. Or perhaps provide a some shered code that can be plugged into both VDSM& the enegine to facilitate provision of the same REST interface.
Indeed, but an API is not just the transport, it is also behavior and error code numbering, etc. trying to develop two different projects trying to do the same thing sounds like quite the overhead to me.
Agreed.
I prefer investing the time in making a lighter version of the engine for a single node. then you would also get the web admin and power user portal if you want them.
Could you flesh out some details on the effort required to implement a light-weight engine? I am concerned that this is more complex than it seems. Also, how would we avoid dual maintenance between the full engine and the light one when a new feature/api is added?
I would use the same engine, moduling out parts not relevant for single node. first we need to move to JBoss AS 7 though to get it to be lighter, then we can look at other angles (make parts of the engine optional, allow it to run with/without jboss, etc.)
On Wed, Nov 30, 2011 at 09:29:23AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote: > > https://github.com/aglitke/vdsm-rest/ > > Today I am releasing a proof of concept implementation of a REST API for vdsm. > You can find the code on github. My goal is to eventually replace the current > xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to > this new API. The major advantages to making this change are: 1) VDSM will gain > a structured API that conceptually, structurally, and functionally aligns with > the ovirt-engine REST API, 2) this new API can be made public, thus providing an > entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip> > ovirt-engine wants to subscribe to asynchronous events. REST APIs do not > typically support async events and instead rely on polling of resources. I am > investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
I tend to agree, using a bus like QMF between ovirt-engine and vdsm is an inherantly more scalable network architecture, since it avoids the need to have a direct point-to-point connection between the engine and every single node, instead you can build a resilient grid by stategically deploying QPid brokers.
As compared to REST, it is also much better at coping with async events, since you can have a push, rather than pull, model which VDSM just puts events onto the bus as they're generated, to be lazily consumed by any remote nodes when desired.
NB, I don't mean to imply that there should not *also* be a REST API for the node level. A REST API has the very compelling property that it is trivially accessible from anything with HTTP client support, which is basically everything in existance today.
My goal is to create a single first-class VDSM API that both ovirt-engine and external applications can use. I am ok with checking out QMF as long as it is distro agnostic and relatively light-weight. In that case, someone (maybe me) could always write a REST interface, but it would merely consume the first-class QMF API. I want to avoid having multiple, parallel APIs to maintain.
2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
If the REST API is well specified, you wouldn't need to necessarily have a lightweight ovirt-engine deployed at the node level, you could just have VDSM implement the same REST specification natively, as is impl in the engine. Or perhaps provide a some shered code that can be plugged into both VDSM & the enegine to facilitate provision of the same REST interface.
Code sharing is hard between the engine and vdsm because the former is Java/C# and vdsm is python. It might be fine to simply expose a single QMF (or whatever) API from vdsm and let some better vdsm interface tools evolve from that (command-line shell, web UI, native app). -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 11/30/2011 10:12 AM, Adam Litke wrote:
My goal is to create a single first-class VDSM API that both ovirt-engine and external applications can use. I am ok with checking out QMF as long as it is distro agnostic and relatively light-weight. In that case, someone (maybe me) could always write a REST interface, but it would merely consume the first-class QMF API. I want to avoid having multiple, parallel APIs to maintain.
If we like, with the RSDL added, I think I could write a bridge that would give you REST & RSDL automatically from QMF. Carl.
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
https://github.com/aglitke/vdsm-rest/
Today I am releasing a proof of concept implementation of a REST API for vdsm. You can find the code on github. My goal is to eventually replace the current xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to this new API. The major advantages to making this change are: 1) VDSM will gain a structured API that conceptually, structurally, and functionally aligns with the ovirt-engine REST API, 2) this new API can be made public, thus providing an entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip>
ovirt-engine wants to subscribe to asynchronous events. REST APIs do not typically support async events and instead rely on polling of resources. I am investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
Thanks!
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
In principle an ovirt-engine-light sounds great. Especially if we could get the existing GUIs for free. The main concern I have with this is the gargantuan nature of the ovirt-engine and GUI code bases. You want to reserve as many system resources for the guests but it seems that ovirt-engine will consume at least several GB of RAM and one or more CPU cores. How would you lighten up this JBoss stack without rewriting it in a more efficient language? One use case I am interested in is a single-node ovirt instance to control VMs on my laptop. I can spare several hundred MB of RAM at most for the management stack. -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 11/30/2011 05:00 PM, Adam Litke wrote:
On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
On 11/29/2011 11:36 PM, Adam Litke wrote:
On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote:
On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
* Adam Litke (agl@us.ibm.com) wrote: > > https://github.com/aglitke/vdsm-rest/ > > Today I am releasing a proof of concept implementation of a REST API for vdsm. > You can find the code on github. My goal is to eventually replace the current > xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to > this new API. The major advantages to making this change are: 1) VDSM will gain > a structured API that conceptually, structurally, and functionally aligns with > the ovirt-engine REST API, 2) this new API can be made public, thus providing an > entry point for direct virtualization management@the node level.
Adam, this looks like a nice PoC. I didn't see how API versioning is handled. Any VDSM developers willing to review this work?
Thanks for taking a look. I am not handling versioning yet. I think we can add a version field to the root API object. As for compatibility, we'll just have to decide on an API backwards-compat support policy. Would this be enough to handle versioning issues? We shouldn't need anything like capabilities because the API is discoverable.
Right, that seems sensible.
Did you find cases where RPC to REST resource mapping was difficult?
I haven't yet fully implemented the current vdsm API but I suspect that certain calls (like the ones you mention below) will require some extensions to what I have available currently. The main missing piece is probably events and a nice polling API. Another big piece of work will be to rebase onto the newly redesigned storage model.
I could see something like migrate() plus migrateStatus() and migrateCancel() needing to add some kind of operational state that to the resource. And something like monitorCommand() which has both a possible side-effect and some freefrom response...
Hopefully monitorCommand will not be too bad, since vdsm should be asking libvirt for the VM details when they are needed. Of course we'll need to be testing to make sure we aren't keeping state around. Also, I would expect monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for libvirt).
<snip> > ovirt-engine wants to subscribe to asynchronous events. REST APIs do not > typically support async events and instead rely on polling of resources. I am > investigating what options are available for supporting async events via REST.
I think typical is either polling or long polling. If it's a single resource, then perhaps long polling would be fine (won't be a large number of connections tied up if it's only a single resource).
Not sure if this is what you are referring to, but I was thinking we could do a batch-polling mechanism where an API user passes in a list of task UUIDs and/or event URIs. The server would respond with the status of these resources in one response. I have some ideas on how we could wire up asynchronous events on the server side to reduce the amount of actual work that such a batch-polling operation would require.
Oh, I just meant this:
Polling (GET /event + 404 loop) Long polling (GET + block ... can chew up a thread connection)
Yep. And we can talk later about building an API for efficient, repeated polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST
cc-ing engine-devel...
interface with event polling would be acceptable to them. It is critical that we settle on an API that can become _the_ first-class vehicle for interacting with vdsm.
Thanks!
i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine).
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
In principle an ovirt-engine-light sounds great. Especially if we could get the existing GUIs for free. The main concern I have with this is the gargantuan nature of the ovirt-engine and GUI code bases. You want to reserve as many system resources for the guests but it seems that ovirt-engine will consume at least several GB of RAM and one or more CPU cores. How would you lighten up this JBoss stack without rewriting it in a more efficient language? One use case I am interested in is a single-node ovirt instance to control VMs on my laptop. I can spare several hundred MB of RAM at most for the management stack.
this is much much lighter and faster with jboss7 (which iirc, takes 100MB to start, tomcat takes 80MB for comparison). then we can look at modularizing/alternatives if still needed.
On 11/30/2011 04:09 PM, Itamar Heim wrote:
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
I'm not sure how hard it is technically. But for ISV's, I can tell you that almost nobody has experience with it. But, is this intended to be a public API though? Regards, Geert
On 11/30/2011 05:32 PM, Geert Jansen wrote:
On 11/30/2011 04:09 PM, Itamar Heim wrote:
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
I'm not sure how hard it is technically. But for ISV's, I can tell you that almost nobody has experience with it.
But, is this intended to be a public API though?
yes, for VDSM. but if we go with ovirt-lite for single node, they will get exactly the same REST API as the full engine has. otherwise they will get a "similar" API, which meand double coding/testing/etc. btw, i think QMF has a REST bridge, but still it will be a different api than going the engine-lite approach.
On Wed, Nov 30, 2011 at 04:32:41PM +0100, Geert Jansen wrote:
On 11/30/2011 04:09 PM, Itamar Heim wrote:
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
I'm not sure how hard it is technically. But for ISV's, I can tell you that almost nobody has experience with it.
But, is this intended to be a public API though?
Yes! Vdsm already has a 'private' API that only RHEV-m used to consume. In the ovirt world, vdsm needs to expose a real public API (by whatever means we choose) so that external entities (ISVs) can leverage vdsm directly if they so choose. This API must be the same one that ovirt-engine uses, otherwise we are maintaining two incompatible APIs. -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On Wed, Nov 30, 2011 at 04:32:41PM +0100, Geert Jansen wrote:
On 11/30/2011 04:09 PM, Itamar Heim wrote:
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
I'm not sure how hard it is technically. But for ISV's, I can tell you that almost nobody has experience with it.
That is not a good sign. Certainly there must be some sort of standardized and well understood API transport that we can use. We're not doing anything particularly novel as far as the API is concerned. -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 11/30/2011 10:52 AM, Adam Litke wrote:
you that almost nobody has experience with it. That is not a good sign. Certainly there must be some sort of standardized and well understood API transport that we can use. We're not doing anything
I'm not sure how hard it is technically. But for ISV's, I can tell particularly novel as far as the API is concerned
There are a bunch of ISV's using it. Doc still lacking in some places but used in massive deployments. Carl.
On 11/30/2011 11:00 PM, Carl Trieloff wrote:
On 11/30/2011 10:52 AM, Adam Litke wrote:
you that almost nobody has experience with it. That is not a good sign. Certainly there must be some sort of standardized and well understood API transport that we can use. We're not doing anything
I'm not sure how hard it is technically. But for ISV's, I can tell particularly novel as far as the API is concerned
That standard is called HTTP :)
There are a bunch of ISV's using it. Doc still lacking in some places but used in massive deployments.
Can you give an examples outside the FSI? And also there's a huge difference between "using it" versus "creating an API for public consumption on top of it". In virtualization, all our competitors APIs are HTTP based (be it SOAP, REST, XML-RPC...) This includes VMware, Microsoft and Citrix. I don't know of any cloud API either that uses something else than HTTP. AMQP may give you a nice bus interface that is helpful as an internal building block to create a distributed application. But I do not see any use of it outside a very small niche. Therefore i do not believe that it is suitable as a transport for an API if that API is for public consumption. Regards, Geert
On 11/30/2011 09:09 AM, Itamar Heim wrote:
On 11/30/2011 05:00 PM, Adam Litke wrote:
single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
In principle an ovirt-engine-light sounds great. Especially if we could get the existing GUIs for free. The main concern I have with this is the gargantuan nature of the ovirt-engine and GUI code bases. You want to reserve as many system resources for the guests but it seems that ovirt-engine will consume at least several GB of RAM and one or more CPU cores. How would you lighten up this JBoss stack without rewriting it in a more efficient language? One use case I am interested in is a single-node ovirt instance to control VMs on my laptop. I can spare several hundred MB of RAM at most for the management stack.
this is much much lighter and faster with jboss7 (which iirc, takes 100MB to start, tomcat takes 80MB for comparison).
When thinking about something like ovirt-node, my concern is that a jboss7 based ovirt-lite would end up significantly impact the size of the image. I think ovirt-node tends to be around ~100MB today which includes VDSM. A simple REST API (as Adam proposes) wouldn't increase this size at all. Just the openjdk package looks to be around 72MB. Regards, Anthony Liguori
On Wed, Nov 30, 2011 at 09:44:19AM -0600, Anthony Liguori wrote:
On 11/30/2011 09:09 AM, Itamar Heim wrote:
On 11/30/2011 05:00 PM, Adam Litke wrote:
single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.
In principle an ovirt-engine-light sounds great. Especially if we could get the existing GUIs for free. The main concern I have with this is the gargantuan nature of the ovirt-engine and GUI code bases. You want to reserve as many system resources for the guests but it seems that ovirt-engine will consume at least several GB of RAM and one or more CPU cores. How would you lighten up this JBoss stack without rewriting it in a more efficient language? One use case I am interested in is a single-node ovirt instance to control VMs on my laptop. I can spare several hundred MB of RAM at most for the management stack.
this is much much lighter and faster with jboss7 (which iirc, takes 100MB to start, tomcat takes 80MB for comparison).
When thinking about something like ovirt-node, my concern is that a jboss7 based ovirt-lite would end up significantly impact the size of the image.
I think ovirt-node tends to be around ~100MB today which includes VDSM. A simple REST API (as Adam proposes) wouldn't increase this size at all.
Just the openjdk package looks to be around 72MB.
IIUC, one of the goals of VDSM is to be a general purpose reusable node agent for non-oVirt management engines to consume too. IME, to maximise the chances of success for broad adoption, simplicity & flexibility are key. Every piece of extra infrastructure a project mandates will reduce the scope for where it can be used. The idea of deploying an ovirt-engine-light just to get a REST based interface to VDSM just doesn't fit in with the simple & flexible approach you need to succeed. Instead of just installing a simple python package, you now need to deploy an entire java app server, and application ontop. Furthermore users who are python developers will be turned off by the idea ofhaving to deal with java, while java developers will be turned off by the idea of relying on this python bit at the bottom of the stack. Similarly if VDSM mandated use of AMQP for all its communication, this would be a turn off for usage from applications which already have a message bus/transport which is not AMQP based. So, IMHO, if VDSM wants to be easily consumable by other non-oVirt based systems, having a native REST API directly implemented in VDSM code is a critical factor to its success. I don't think this is mutually exclusive with having AMQP used for comms between VDSM & ovirt-engine. One possible implementation strategy would be to have a 'vdsm-qmf' agent running on the node which talks REST to VDSM and translate it to QMF & vica-verca. Or you could have an optional plugin for VDSM which enabled AQMP as an alternative to REST. The key is really to ensure that VDSM retains the ability to be deployed with minimal mandatory infrastructure burden/reqiurements. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
* Daniel P. Berrange (berrange@redhat.com) wrote:
I don't think this is mutually exclusive with having AMQP used for comms between VDSM & ovirt-engine. One possible implementation strategy would be to have a 'vdsm-qmf' agent running on the node which talks REST to VDSM and translate it to QMF & vica-verca. Or you could have an optional plugin for VDSM which enabled AQMP as an alternative to REST.
Right, there are a number of AMQP <-> REST projects out there, so shouldn't be mutually exclusive.
The key is really to ensure that VDSM retains the ability to be deployed with minimal mandatory infrastructure burden/reqiurements.
I completely agree. thanks, -chris
We had a very useful discussion on IRC regarding these ideas. Here is that transcript for those of you who are interested: <danken> aglitke: I have, thanks to Chris Write <danken> I know I should chime in, as well as smizrahi I suppose. <aglitke> yep... Would be good to get some additional perspectives. <aglitke> QMF is being pushed hard at the moment. <aglitke> Or an ovirt-engine light (which I am dubious of) <smizrahi> Well, I'm really for QMF (or anything else that supports messaging. <smizrahi> We can't scale if we have to be polled for everything <aglitke> I guess I don't understand the multiple ovirt-engine use case? When would multple engines control the same node at the same time? <aliguori> rest can support notifications <aliguori> there's nothing that says that an HTTP request has to return in any amount of time <aglitke> If you need a bus in the engine, just write a QMF broker in your code that consumes the rest APi <aliguori> you can have an event collection, and fetch it using that as a mechanism to receive async events <aglitke> Then you can fill your engine code with QMF consoles to spread those events around. <aliguori> it's certainly not pub/sub, but you don't have to do polling <smizrahi> aliguori: http requests do time out. You actually do want them to time out. Also we want to announce things like "network disappeared" and "machine crashed which shouldn't just have a request waiting for them. <aliguori> with real web servers over proxies, yes <danpb> aglitke: sure you could certainly write the QMF agent for the node which talks REST to VDSM <danpb> you could even argue that would be good because it would keep VDSM de-coupled from the messaging service <danpb> as long as the QMF agent & VDSM were on the same node most of the performance questions around REST vs QMF would then be irrelevant, because REST usage would never stray outside the local node for the ovirt-engine <-> vdsm comms path <aliguori> indeed <smizrahi> well, as the main consumer of the API would never use the REST API. Why is it even good? <smizrahi> Just have everyone use AMF <smizrahi> QMF <danpb> well it depends on what other consumers of VDSM are around <smizrahi> I don;t think that any consumer looking to scale would rather use the REST API <danpb> or whether VDSM were intended to be used standarlone outside RHEVM <danpb> or were expecting to be easily integrated with other mgmt systems <aglitke> We would like to be able to use vdsm standalone as a basic requirement. <smizrahi> danpb: I would love to see it used outside ovirt-engine <aglitke> There are cases where not all ovirt consumers will want all of the pieces. <smizrahi> The point being, if ovirt-engine found it necessary to use QMF, why shouldn't any other users <danpb> eg, if some other 3rd party came along and wanted to use VDSM in their app, but already has a comms system/bus that is not AMQP, then integration will liekly be easier via REST <smizrahi> apart from the obvious simplicity of REST <smizrahi> danpb: you do have a point there <danpb> smizrahi: IME simplicity of use is key to getting adoption - every piece of extra infrastructure you mandate, reduces your pool of consumers <danpb> a good % of people will simply not even consider VDSM if it mandated QMF, whereas everyone in today's world can trivially use REST <aglitke> Also, ovirt-engine can modularize their consumption via QMF such that other projects could pick that up if they wanted to use it. <aglitke> It's all about building blocks in my mind. <smizrahi> I see how the AMF proxy xould just be on the host <smizrahi> QMF <smizrahi> and we'd have a dedicated collectEvents API call <aglitke> yes. I also have some ideas on how to make this interface efficient in vdsm <aglitke> you could create a resource called an event sink or event monitor <aglitke> this would essentially be a list of events and task ids you want to watch. <smizrahi> Ho will async operation work. We would like to have all operations be asynchronous <smizrahi> How <aglitke> when this is created, it tells vdsm to set up some internal async handlers to cache the status of these tasks/events. <smizrahi> yea but them shotrt living tasks have a large overhead <smizrahi> as they are bound by the minimum collect interval <aglitke> For those, you would just use the standard polling <aglitke> aliguori suggested having a single. global event / task source that you could connect to. <aglitke> danpb suggested using keepalive or chunking <aliguori> smizrahi, so a QMF -> REST bridge wouldn't be a bad thing either IMHO <smizrahi> We could technically optimize single host scenarios with a polling a pipe hinting you to collet <aliguori> i don't really care how things are implemented <aliguori> but QMF is an obscure protocol today <aglitke> if we did this, the server could send out things as they happen. <aliguori> REST is becoming the defacto standard management interface <smizrahi> I would like to get abarons point of view. Too bad he missed this. <aglitke> I can post it to the mailing list. <aglitke> Do we have a marginal consensus among those of us participating here? <aliguori> smizrahi, REST is really a compromise, if it wasn't REST, I'd be advocating CIM ;-) <aglitke> yuck <smizrahi> I would still like to get event handling nailed down before we go full throttle on this <smizrahi> but I would rather it happening on the mailing lists as all the bigshots are not here <aglitke> Yeah, I'll try to take a stab at summarizing the thoughts here. Then I will post to the list for comments with a more thorough writeup... <smizrahi> aglitke: excellent <aglitke> Summary of potential architecture: <aglitke> 1. VDSM adopts a REST API as the lowest level API <aglitke> 2. we create a QMF broker that consumes the rest API and exposes a bus to the engine <aglitke> 3. The engine can add any number of QMF consoles to this bus for things like stats, logging, reports, etc. <aglitke> 4. ISVs may interact with vdsm directly via its REST API <aglitke> Outstanding issues: <aglitke> 1. We must flesh out how events will be presented in the REST API (including the mechanism) <aglitke> ... <aglitke> aliguori, danpb, smizrahi: Agreed on these high-level points? <danpb> aglitke: yeah, that's a viable plan to me <aliguori> ack <smizrahi> One of the things I worry is problems with putting ovirt-engine specific logic in the QMF brgide <smizrahi> I would like to stress that the bridge has to be ovirt-engine specific <smizrahi> or at least to the same messaging API -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
On 11/30/2011 10:09 AM, Itamar Heim wrote:
How easy is QMF to consume from a software development perspective? Would it be easy for someone to write a virsh-like tool against a QMF-based vdsm API? Would such a tool be able to run on multiple Linux distributions?
it is supposed to have a cli console. cc'ing carl and Ted for more details.
yes it is dirt easy, and there are also a bunch of generic tools to script against QMF with. i.e. you can call just about anything in QMF with about 4-5 lines of script. Carl.
participants (7)
-
Adam Litke -
Anthony Liguori -
Carl Trieloff -
Chris Wright -
Daniel P. Berrange -
Geert Jansen -
Itamar Heim