4:40 p.m.
Recently we've had some very productive discussions concerning the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to emerge:
Create a REST API that will provide all of the functionality that is currently
available via the xmlrpc interface (with the goal of deprecating xmlrpc once it
becomes mature enough). To support advanced clustering features that
ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API
onto a message bus. ovirt-engine will interact with vdsm exclusively over this
bus but the REST API will be the principle API and the entry point for ISV apps.
A REST API provides a light-weight and standard way to access all of the vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at the api
root. REST users will use some sort of polling to collect these events. The
details of this interface are being worked on. Several ways for minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
5:37 p.m.
Hi,
i think this makes sense, but i'm not a VDSM expert. I did want to point
out one other point, below:
On 11/30/2011 11:40 PM, Adam Litke wrote:
Recently we've had some very productive discussions concerning
the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
I have doubts around how useful the VDSM API will be for creating an
ecosystem. If you look at most virtualization ISVs today, they want to
integrate with a multi-node API and not a single-node API. The only use
case that i know where integrating with a single node API is requested
is when you're basically creating a virtualization management platform
like oVirt itself.
[Since we haven't met before, a brief intro... I have been responsible
at Red Hat for buiding our virtualization ecosystem for the past year or
so.]
Regards,
Geert
10:32 p.m.
-----Original Message-----
From: Adam Litke [mailto:agl@us.ibm.com]
Sent: Thursday, December 01, 2011 0:41 AM
To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)ovirt.org
Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar Heim
Subject: Proposed next-generation vdsm API
Recently we've had some very productive discussions concerning the VDSM
API.
I
want to attempt to refocus the discussion around an emerging proposal
and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements
that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to
emerge:
Create a REST API that will provide all of the functionality that is
currently
available via the xmlrpc interface (with the goal of deprecating
xmlrpc
once it
becomes mature enough). To support advanced clustering features
that
ovirt-engine is planning, we'll write an QMF broker that can proxy the
REST
API
onto a message bus. ovirt-engine will interact with vdsm exclusively
over this
bus but the REST API will be the principle API and the entry point
for
ISV apps.
A REST API provides a light-weight and standard way to access all of
the
vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at
the api
root. REST users will use some sort of polling to collect these
events.
The
details of this interface are being worked on. Several ways for
minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like
to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!
Why things non native to REST and wrap it in QMF, rather than do the
reverse?
Or just to them in parallel, since it sounds like both are going to be
first class citizens?
1:02 a.m.
----- Original Message -----
> -----Original Message-----
> From: Adam Litke [mailto:agl@us.ibm.com]
> Sent: Thursday, December 01, 2011 0:41 AM
> To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)ovirt.org
> Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar Heim
> Subject: Proposed next-generation vdsm API
>
> Recently we've had some very productive discussions concerning the
> VDSM
API. I
> want to attempt to refocus the discussion around an emerging
> proposal
and see if
> we can agree on a sensible path forward.
>
> Based on the discussion, I have identified the following
> requirements
that
> a new API for vdsm should have:
>
> 1.) Single API that can be consumed by ovirt-engine and ISVs
> - We don't want to maintain multiple parallel APIs
> - To develop a vendor ecosystem, we must have a robust external
> API to
> vdsm
>
> 2.) Full vdsm capabilities are exposed without requiring
> ovirt-engine
> - ovirt components should be modular and independently useful
> - Some deployments might want to manage nodes without ovirt-engine
>
> 3.) Standardized protocol with low overhead
> - Required for widespread adoption
>
> 4.) Support for asynchronous tasks and events
> - Needed by ovirt-engine and other consumers
>
> Based on these requirements, the following proposal has started to
emerge:
>
> Create a REST API that will provide all of the functionality that
> is
currently
> available via the xmlrpc interface (with the goal of deprecating
> xmlrpc
once it
> becomes mature enough). To support advanced clustering features
> that
> ovirt-engine is planning, we'll write an QMF broker that can proxy
> the
REST API
> onto a message bus. ovirt-engine will interact with vdsm
> exclusively
over this
> bus but the REST API will be the principle API and the entry point
> for
ISV apps.
> A REST API provides a light-weight and standard way to access all
> of the
vdsm
> functionality.
>
> The REST API will handle events by exposing a new 'events'
> collection at
the api
> root. REST users will use some sort of polling to collect these
> events.
The
> details of this interface are being worked on. Several ways for
minimizing the
> impact of polling have been discussed. The QMF broker can expose a
> publish/subscribe model for events as appropriate.
>
> Is this model an acceptable way to improve the vdsm API? I would
> like
to hear
> the opinions of ovirt-engine developers, vdsm developers, and other
> stakeholders. Thanks for providing feedback on this proposal!
Why things non native to REST and wrap it in QMF, rather than do the
reverse?
Or just to them in parallel, since it sounds like both are going to
be
first class citizens?
This was more my understanding from our discussion on IRC yesterday.
REST API - everything that is relevant for single node management
QMF - same API as above + multi-node relevant API calls. I don't see any reason for
doing weird things over REST to support the latter.
In fact, I don't even see any real reason for going through the REST API when using
QMF.
If you take a look at today's API you will see that there is nothing there that limits
it to XML-RPC and we could easily expose all the calls using REST or anything else.
In python, exposing a new verb in the various APIs can be automatic so this would require
very little maintenance. Any multi-node or transport specific calls can be decorated as
such and would be automatically ignored/picked up by the relevant API layer.
This way, we could also easily enable using different bus protocols assuming a customer
already has a deployment as was suggested yesterday.
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
12:33 p.m.
On 11/30/2011 05:40 PM, Adam Litke wrote:
Recently we've had some very productive discussions concerning
the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to emerge:
Create a REST API that will provide all of the functionality that is currently
available via the xmlrpc interface
I just want to stress that it WILL deprecate and
significantly change
some aspects of the API most obvious are the task aspects of the API.
Even though the commands might be the same the current async\sync task
semantics might change to better accommodate the QMF wrapper and other
users. I don't think it's needed to go into details now but I am
stressing that there WILL be API calls the will not migrate or
significantly change in the REST API.
(with the goal of deprecating xmlrpc once it
becomes mature enough). To support advanced clustering features that
ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API
onto a message bus. ovirt-engine will interact with vdsm exclusively over this
bus but the REST API will be the principle API and the entry point for ISV apps.
A REST API provides a light-weight and standard way to access all of the vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at the api
root. REST users will use some sort of polling to collect these events. The
details of this interface are being worked on. Several ways for minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!
12:35 p.m.
On Thu, Dec 01, 2011 at 12:37:00AM +0100, Geert Jansen wrote:
Hi,
i think this makes sense, but i'm not a VDSM expert. I did want to
point out one other point, below:
On 11/30/2011 11:40 PM, Adam Litke wrote:
>Recently we've had some very productive discussions concerning the VDSM API. I
>want to attempt to refocus the discussion around an emerging proposal and see if
>we can agree on a sensible path forward.
>
>Based on the discussion, I have identified the following requirements that
>a new API for vdsm should have:
>
>1.) Single API that can be consumed by ovirt-engine and ISVs
> - We don't want to maintain multiple parallel APIs
> - To develop a vendor ecosystem, we must have a robust external API to
> vdsm
I have doubts around how useful the VDSM API will be for creating an
ecosystem. If you look at most virtualization ISVs today, they want
to integrate with a multi-node API and not a single-node API. The
only use case that i know where integrating with a single node API
is requested is when you're basically creating a virtualization
management platform like oVirt itself.
A single-node (or standalone VDSM deployment) is a very important use case.
Many people are coming into the oVirt community from different perspectives.
The strength of the ecosystem depends, in part, on the ability of oVirt
components to be combined in unique ways with other software to produce
solutions. The complete oVirt stack is a great thing, but not the only way to
use the technology.
[Since we haven't met before, a brief intro... I have been
responsible at Red Hat for buiding our virtualization ecosystem for
the past year or so.]
Hi and thanks for the introduction! I look forward to working with you and the
rest of the oVirt community on these issues :)
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12:40 p.m.
On Wed, Nov 30, 2011 at 11:32:55PM -0500, Itamar Heim wrote:
> -----Original Message-----
> From: Adam Litke [mailto:agl@us.ibm.com]
> Sent: Thursday, December 01, 2011 0:41 AM
> To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)ovirt.org
> Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar Heim
> Subject: Proposed next-generation vdsm API
>
> Recently we've had some very productive discussions concerning the VDSM
API. I
> want to attempt to refocus the discussion around an emerging proposal
and see if
> we can agree on a sensible path forward.
>
> Based on the discussion, I have identified the following requirements
that
> a new API for vdsm should have:
>
> 1.) Single API that can be consumed by ovirt-engine and ISVs
> - We don't want to maintain multiple parallel APIs
> - To develop a vendor ecosystem, we must have a robust external API to
> vdsm
>
> 2.) Full vdsm capabilities are exposed without requiring ovirt-engine
> - ovirt components should be modular and independently useful
> - Some deployments might want to manage nodes without ovirt-engine
>
> 3.) Standardized protocol with low overhead
> - Required for widespread adoption
>
> 4.) Support for asynchronous tasks and events
> - Needed by ovirt-engine and other consumers
>
> Based on these requirements, the following proposal has started to
emerge:
>
> Create a REST API that will provide all of the functionality that is
currently
> available via the xmlrpc interface (with the goal of deprecating xmlrpc
once it
> becomes mature enough). To support advanced clustering features that
> ovirt-engine is planning, we'll write an QMF broker that can proxy the
REST API
> onto a message bus. ovirt-engine will interact with vdsm exclusively
over this
> bus but the REST API will be the principle API and the entry point for
ISV apps.
> A REST API provides a light-weight and standard way to access all of the
vdsm
> functionality.
>
> The REST API will handle events by exposing a new 'events' collection at
the api
> root. REST users will use some sort of polling to collect these events.
The
> details of this interface are being worked on. Several ways for
minimizing the
> impact of polling have been discussed. The QMF broker can expose a
> publish/subscribe model for events as appropriate.
>
> Is this model an acceptable way to improve the vdsm API? I would like
to hear
> the opinions of ovirt-engine developers, vdsm developers, and other
> stakeholders. Thanks for providing feedback on this proposal!
Why things non native to REST and wrap it in QMF, rather than do the
reverse?
Or just to them in parallel, since it sounds like both are going to be
first class citizens?
Parallel APIs mean dual maintenance. There will be inherent incompatibilities
as each API would naturally have small differences. The reason for beginning
with REST because of its low overhead and simplicity. Users of the REST API
would not need to concern themselves with QMF at all but if that extra set of
features is desired it can be easily added.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12:42 p.m.
On 12/01/2011 07:35 PM, Adam Litke wrote:
A single-node (or standalone VDSM deployment) is a very important use
case.
Many people are coming into the oVirt community from different perspectives.
The strength of the ecosystem depends, in part, on the ability of oVirt
components to be combined in unique ways with other software to produce
solutions. The complete oVirt stack is a great thing, but not the only way to
use the technology.
Just out of curiosity: what might those single node cases be, outside
implementing an oVirt like solution? I think understanding those better
is also critical input to the API design.
Regards,
Geert
1:10 p.m.
On Thu, Dec 01, 2011 at 02:02:27AM -0500, Ayal Baron wrote:
----- Original Message -----
>
>
> > -----Original Message-----
> > From: Adam Litke [mailto:agl@us.ibm.com]
> > Sent: Thursday, December 01, 2011 0:41 AM
> > To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)ovirt.org
> > Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar Heim
> > Subject: Proposed next-generation vdsm API
> >
> > Recently we've had some very productive discussions concerning the
> > VDSM
> API. I
> > want to attempt to refocus the discussion around an emerging
> > proposal
> and see if
> > we can agree on a sensible path forward.
> >
> > Based on the discussion, I have identified the following
> > requirements
> that
> > a new API for vdsm should have:
> >
> > 1.) Single API that can be consumed by ovirt-engine and ISVs
> > - We don't want to maintain multiple parallel APIs
> > - To develop a vendor ecosystem, we must have a robust external
> > API to
> > vdsm
> >
> > 2.) Full vdsm capabilities are exposed without requiring
> > ovirt-engine
> > - ovirt components should be modular and independently useful
> > - Some deployments might want to manage nodes without ovirt-engine
> >
> > 3.) Standardized protocol with low overhead
> > - Required for widespread adoption
> >
> > 4.) Support for asynchronous tasks and events
> > - Needed by ovirt-engine and other consumers
> >
> > Based on these requirements, the following proposal has started to
> emerge:
> >
> > Create a REST API that will provide all of the functionality that
> > is
> currently
> > available via the xmlrpc interface (with the goal of deprecating
> > xmlrpc
> once it
> > becomes mature enough). To support advanced clustering features
> > that
> > ovirt-engine is planning, we'll write an QMF broker that can proxy
> > the
> REST API
> > onto a message bus. ovirt-engine will interact with vdsm
> > exclusively
> over this
> > bus but the REST API will be the principle API and the entry point
> > for
> ISV apps.
> > A REST API provides a light-weight and standard way to access all
> > of the
> vdsm
> > functionality.
> >
> > The REST API will handle events by exposing a new 'events'
> > collection at
> the api
> > root. REST users will use some sort of polling to collect these
> > events.
> The
> > details of this interface are being worked on. Several ways for
> minimizing the
> > impact of polling have been discussed. The QMF broker can expose a
> > publish/subscribe model for events as appropriate.
> >
> > Is this model an acceptable way to improve the vdsm API? I would
> > like
> to hear
> > the opinions of ovirt-engine developers, vdsm developers, and other
> > stakeholders. Thanks for providing feedback on this proposal!
>
> Why things non native to REST and wrap it in QMF, rather than do the
> reverse?
> Or just to them in parallel, since it sounds like both are going to
> be
> first class citizens?
This was more my understanding from our discussion on IRC yesterday.
I'm afraid I did not follow that discussion to your conclusions...
REST API - everything that is relevant for single node management
QMF - same API as above + multi-node relevant API calls. I don't see any
reason for doing weird things over REST to support the latter.
A QMF broker runs on the vdsm host and talks to the REST API. It connects to a
bus and exposes an API to ovirt-engine on this bus using a vdsm-base schema.
ovirt-engine wants additional clustering functionality. This API should be
implemented completely between the QMF broker and ovirt-engine using a separate
vdsm-cluster schema.
In fact, I don't even see any real reason for going through the
REST API when
using QMF.
Because we want to avoid the proliferation of APIs. I would prefer a mostly
vertical chain of API components to a vdsm with several independent APIs (which
are sure to diverge or be neglected by individual developers/patches).
If you take a look at today's API you will see that there is
nothing there
that limits it to XML-RPC and we could easily expose all the calls using REST
or anything else. In python, exposing a new verb in the various APIs can be
automatic so this would require very little maintenance. Any multi-node or
transport specific calls can be decorated as such and would be automatically
ignored/picked up by the relevant API layer. This way, we could also easily
enable using different bus protocols assuming a customer already has a
deployment as was suggested yesterday.
I don't think this will be as automatic as you suggest in practice. It sounds
like it will increase code complexity, obfuscation, and maintenance burden.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
1:21 p.m.
On 12/01/2011 01:42 PM, Geert Jansen wrote:
On 12/01/2011 07:35 PM, Adam Litke wrote:
> A single-node (or standalone VDSM deployment) is a very important use
> case.
> Many people are coming into the oVirt community from different
> perspectives.
> The strength of the ecosystem depends, in part, on the ability of oVirt
> components to be combined in unique ways with other software to produce
> solutions. The complete oVirt stack is a great thing, but not the
> only way to
> use the technology.
Just out of curiosity: what might those single node cases be, outside
implementing an oVirt like solution? I think understanding those
better is also critical input to the API design.
I would personally really like to see a server distro that installs
virtual appliances instead of packages. With that I could have a server
with a DHCP\httpd\mail server\webdav\IPA appliances running on the host
completely separate using qemu or even lxc. Having a BL and UI around
that would be very convenient for small setups and home servers. VDSM
would be handy for storage, network and policy configuration as well as
tracking the appliances stats.
Geert
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:40 p.m.
* Geert Jansen <gjansen(a)redhat.com> [2011-11-30 17:38]:
Hi,
i think this makes sense, but i'm not a VDSM expert. I did want to point
out one other point, below:
On 11/30/2011 11:40 PM, Adam Litke wrote:
> Recently we've had some very productive discussions concerning the VDSM API. I
> want to attempt to refocus the discussion around an emerging proposal and see if
> we can agree on a sensible path forward.
>
> Based on the discussion, I have identified the following requirements that
> a new API for vdsm should have:
>
> 1.) Single API that can be consumed by ovirt-engine and ISVs
> - We don't want to maintain multiple parallel APIs
> - To develop a vendor ecosystem, we must have a robust external API to
> vdsm
I have doubts around how useful the VDSM API will be for creating an
ecosystem. If you look at most virtualization ISVs today, they want to
integrate with a multi-node API and not a single-node API. The only use
case that i know where integrating with a single node API is requested
is when you're basically creating a virtualization management platform
like oVirt itself.
Without a first-class node level API, we're precluding the very case
you're aware of. If we're building a community and ecosystem
around KVM management then we need to be open to someone building that
management platform and doing it in a way that keeps things compatible.
There are existing products (IBM has a number in this space) which
utilize libvirt as a node-level API which won't be able to (easily)
integrate all of oVirt just to obtain access to the nodes.
Further, if the only way to consume VDSM is via the multi-node solution, then
price of entry is a much larger, more complex stack with more
dependencies. This raises the barrier of entry and participation.
IMHO, not ideal when we're attempting to grow a community.
Alternatively, if we enable a common node API, not only do we support
single node deployments (think virtual appliances, or hardware
appliances; IBM has a few of these) but allowing competing (but
compatible) multi-node/cluster solutions; and it even supports
the single node solutions to be managed by different kvm-based
management platforms because they're all working with the same
node-level API.
Having a first-class node API is a critical starting point for building
our larger kvm management community since it allows for easier
integration of existing products. I cannot stress that point enough; if
we're committed to being an open community then we need design our
interfaces to encourage participation. Lowing the cost of participation
and integrate is great way to enable an ecosystem.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
4:54 p.m.
On 12/01/2011 12:42 PM, Geert Jansen wrote:
On 12/01/2011 07:35 PM, Adam Litke wrote:
> A single-node (or standalone VDSM deployment) is a very important use case.
> Many people are coming into the oVirt community from different perspectives.
> The strength of the ecosystem depends, in part, on the ability of oVirt
> components to be combined in unique ways with other software to produce
> solutions. The complete oVirt stack is a great thing, but not the only way to
> use the technology.
Just out of curiosity: what might those single node cases be, outside
implementing an oVirt like solution?
ovirt-engine currently doesn't handle every possible scenario where you want to
manage more than one physical machine. And while I'm sure total world
domination is not that far away, there's going to be a time period where there
continues to be use cases it is not suited for.
To name a few:
1) Fixed environments where a handful of systems are needed with some level of
scripting used to coordinate things. Using a full three tier management server
would be too much for this environment. This isn't necessarily a small
deployment, this may be a huge number of small deployments (think half a dozen
blades in the back of a retail store times 5,000).
2) Massive scale clusters. I'm talking Top 500 scale. There are people out
there doing this with KVM today. They use tools like xCat and write directly
against libvirt. But libvirt's lack of policy makes this harder than it should be.
3) Environments where virtualization is not the primary workload. There are a
lot of cloud-like environments that are built with physical hardware only. In
these cases, there is an existing infrastructure that does a lot of what oVirt
does. It's easier for these environments to treat VMs as physical machines.
As much as it's important to focus on the top-down view of oVirt as a cohesive
stack, it's also important to look at each layer and make sure that each layer
stands on its own.
It's an 90/10 thing. You need a strong node-level interface to cover that last
10% of use-cases unless you're willing to spend 90% of the effort trying to also
accommodate them.
Regards,
Anthony Liguori
I think understanding those better
is also critical input to the API design.
Regards,
Geert
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
4:22 p.m.
----- Original Message -----
* Geert Jansen <gjansen(a)redhat.com> [2011-11-30 17:38]:
> Hi,
>
> i think this makes sense, but i'm not a VDSM expert. I did want to
> point
> out one other point, below:
>
> On 11/30/2011 11:40 PM, Adam Litke wrote:
> > Recently we've had some very productive discussions concerning
> > the VDSM API. I
> > want to attempt to refocus the discussion around an emerging
> > proposal and see if
> > we can agree on a sensible path forward.
> >
> > Based on the discussion, I have identified the following
> > requirements that
> > a new API for vdsm should have:
> >
> > 1.) Single API that can be consumed by ovirt-engine and ISVs
> > - We don't want to maintain multiple parallel APIs
> > - To develop a vendor ecosystem, we must have a robust external
> > API to
> > vdsm
>
> I have doubts around how useful the VDSM API will be for creating
> an
> ecosystem. If you look at most virtualization ISVs today, they want
> to
> integrate with a multi-node API and not a single-node API. The only
> use
> case that i know where integrating with a single node API is
> requested
> is when you're basically creating a virtualization management
> platform
> like oVirt itself.
Without a first-class node level API, we're precluding the very case
you're aware of. If we're building a community and ecosystem
around KVM management then we need to be open to someone building
that
management platform and doing it in a way that keeps things
compatible.
There are existing products (IBM has a number in this space) which
utilize libvirt as a node-level API which won't be able to (easily)
integrate all of oVirt just to obtain access to the nodes.
Further, if the only way to consume VDSM is via the multi-node
solution, then
price of entry is a much larger, more complex stack with more
dependencies. This raises the barrier of entry and participation.
IMHO, not ideal when we're attempting to grow a community.
Alternatively, if we enable a common node API, not only do we support
single node deployments (think virtual appliances, or hardware
appliances; IBM has a few of these) but allowing competing (but
compatible) multi-node/cluster solutions; and it even supports
the single node solutions to be managed by different kvm-based
management platforms because they're all working with the same
node-level API.
Having a first-class node API is a critical starting point for
building
our larger kvm management community since it allows for easier
integration of existing products. I cannot stress that point enough;
if
we're committed to being an open community then we need design our
interfaces to encourage participation. Lowing the cost of
participation
and integrate is great way to enable an ecosystem.
+1
The REST-API should be exactly this.
For multi-node environments where things are already complex we can raise the bar of
demands, but for single node it has to be simple and straight-forward with very few
requirements (i.e. requiring amqp in single-node use case is too complicated).
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
4:25 p.m.
----- Original Message -----
On Thu, Dec 01, 2011 at 02:02:27AM -0500, Ayal Baron wrote:
>
>
> ----- Original Message -----
> >
> >
> > > -----Original Message-----
> > > From: Adam Litke [mailto:agl@us.ibm.com]
> > > Sent: Thursday, December 01, 2011 0:41 AM
> > > To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)ovirt.org
> > > Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar
> > > Heim
> > > Subject: Proposed next-generation vdsm API
> > >
> > > Recently we've had some very productive discussions concerning
> > > the
> > > VDSM
> > API. I
> > > want to attempt to refocus the discussion around an emerging
> > > proposal
> > and see if
> > > we can agree on a sensible path forward.
> > >
> > > Based on the discussion, I have identified the following
> > > requirements
> > that
> > > a new API for vdsm should have:
> > >
> > > 1.) Single API that can be consumed by ovirt-engine and ISVs
> > > - We don't want to maintain multiple parallel APIs
> > > - To develop a vendor ecosystem, we must have a robust
> > > external
> > > API to
> > > vdsm
> > >
> > > 2.) Full vdsm capabilities are exposed without requiring
> > > ovirt-engine
> > > - ovirt components should be modular and independently useful
> > > - Some deployments might want to manage nodes without
> > > ovirt-engine
> > >
> > > 3.) Standardized protocol with low overhead
> > > - Required for widespread adoption
> > >
> > > 4.) Support for asynchronous tasks and events
> > > - Needed by ovirt-engine and other consumers
> > >
> > > Based on these requirements, the following proposal has started
> > > to
> > emerge:
> > >
> > > Create a REST API that will provide all of the functionality
> > > that
> > > is
> > currently
> > > available via the xmlrpc interface (with the goal of
> > > deprecating
> > > xmlrpc
> > once it
> > > becomes mature enough). To support advanced clustering
> > > features
> > > that
> > > ovirt-engine is planning, we'll write an QMF broker that can
> > > proxy
> > > the
> > REST API
> > > onto a message bus. ovirt-engine will interact with vdsm
> > > exclusively
> > over this
> > > bus but the REST API will be the principle API and the entry
> > > point
> > > for
> > ISV apps.
> > > A REST API provides a light-weight and standard way to access
> > > all
> > > of the
> > vdsm
> > > functionality.
> > >
> > > The REST API will handle events by exposing a new 'events'
> > > collection at
> > the api
> > > root. REST users will use some sort of polling to collect
> > > these
> > > events.
> > The
> > > details of this interface are being worked on. Several ways
> > > for
> > minimizing the
> > > impact of polling have been discussed. The QMF broker can
> > > expose a
> > > publish/subscribe model for events as appropriate.
> > >
> > > Is this model an acceptable way to improve the vdsm API? I
> > > would
> > > like
> > to hear
> > > the opinions of ovirt-engine developers, vdsm developers, and
> > > other
> > > stakeholders. Thanks for providing feedback on this proposal!
> >
> > Why things non native to REST and wrap it in QMF, rather than do
> > the
> > reverse?
> > Or just to them in parallel, since it sounds like both are going
> > to
> > be
> > first class citizens?
>
> This was more my understanding from our discussion on IRC
> yesterday.
I'm afraid I did not follow that discussion to your conclusions...
> REST API - everything that is relevant for single node management
> QMF - same API as above + multi-node relevant API calls. I don't
> see any
> reason for doing weird things over REST to support the latter.
A QMF broker runs on the vdsm host and talks to the REST API. It
connects to a
bus and exposes an API to ovirt-engine on this bus using a vdsm-base
schema.
ovirt-engine wants additional clustering functionality. This API
should be
implemented completely between the QMF broker and ovirt-engine using
a separate
vdsm-cluster schema.
> In fact, I don't even see any real reason for going through the
> REST API when
> using QMF.
Because we want to avoid the proliferation of APIs. I would prefer a
mostly
vertical chain of API components to a vdsm with several independent
APIs (which
are sure to diverge or be neglected by individual
developers/patches).
> If you take a look at today's API you will see that there is
> nothing there
> that limits it to XML-RPC and we could easily expose all the calls
> using REST
> or anything else. In python, exposing a new verb in the various
> APIs can be
> automatic so this would require very little maintenance. Any
> multi-node or
> transport specific calls can be decorated as such and would be
> automatically
> ignored/picked up by the relevant API layer. This way, we could
> also easily
> enable using different bus protocols assuming a customer already
> has a
> deployment as was suggested yesterday.
I don't think this will be as automatic as you suggest in practice.
It sounds
like it will increase code complexity, obfuscation, and maintenance
burden.
Even today we don't really have any reliance on the transport.
The beauty of REST is its simplicity, but with that come limitations. If we require the
qmf API to go through REST then we're basically limiting the qmf to the REST
shortcomings or we implement things that bend REST the wrong way to accomodate the extra
requirements.
For any "simple" call I'm fine with qmf going through REST if it simplifies
maintenance, but for things like events, I believe there is no justification for going
through REST.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
4527
days inactive
4530
days old
13 comments
7 participants
participants (7)
-
Adam Litke -
Anthony Liguori -
Ayal Baron -
Geert Jansen -
Itamar Heim -
Ryan Harper -
Saggi Mizrahi