5:23 a.m.
Dear all,
You may find of interest a new implementation of the libvirt
virtualization API. This new implementation adds support to OpenNebula, a
distributed VM manager system. The implementation of libvirt on top of a
distributed VM manager, like OpenNebula, provides an abstraction of a whole
cluster of resources (each one with its hypervisor). In this way, you can use
any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a
distributed level.
For example, you may create a new domain with 'virsh create', then OpenNebula
will look for a suitable resource, transfer the VM images and boot your VM
using any of the supported hypervisors. The distributed management is
completely transparent to the libvirt application. This is, a whole cluster
can be managed as any other libvirt node.
The current implementation is targeted for libvirt 0.4.4, and includes a patch
to the libvirt source tree (mainly to modify the autotools files), and a
libvirt driver.
More information and download instructions can be found at:
* http://trac.opennebula.org/wiki/LibvirtOpenNebula
* http://www.opennebula.org
Cheers
Ruben
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
9:43 a.m.
On Mon, Nov 03, 2008 at 12:23:47PM +0100, Ruben S. Montero wrote:
Dear all,
You may find of interest a new implementation of the libvirt
virtualization API. This new implementation adds support to OpenNebula, a
distributed VM manager system. The implementation of libvirt on top of a
distributed VM manager, like OpenNebula, provides an abstraction of a whole
cluster of resources (each one with its hypervisor). In this way, you can use
any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a
distributed level.
For example, you may create a new domain with 'virsh create', then OpenNebula
will look for a suitable resource, transfer the VM images and boot your VM
using any of the supported hypervisors. The distributed management is
completely transparent to the libvirt application. This is, a whole cluster
can be managed as any other libvirt node.
The current implementation is targeted for libvirt 0.4.4, and includes a patch
to the libvirt source tree (mainly to modify the autotools files), and a
libvirt driver.
More information and download instructions can be found at:
* http://trac.opennebula.org/wiki/LibvirtOpenNebula
* http://www.opennebula.org
Interesting, but this raises a couple of questions:
- isn't OpenNebula in some way also an abstraction layer for the
hypervisors, so in a sense a libvirt driver for OpenNebula
is a bit 'redundant' ? Maybe i didn't understood well the
principles behind OpenNebula :-) (sorry first time I learn about
this).
- what is the future of that patch ? Basically libvirt internals
changes extremely fast, so unless a driver gets included as part
of libvirt own code source, there is a lot of maintainance and
usability problems resulting from the split. Do you intent to
submit it for inclusion, or is that more a trial to gauge interest ?
Submitting the driver for inclusion means the code will have to be
reviewed, released under LGPL, and a voluteer should be available
for future maintainance and integration issues.
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:26 a.m.
Hi Daniel
On Monday 03 November 2008 16:43:32 Daniel Veillard wrote:
Interesting, but this raises a couple of questions:
- isn't OpenNebula in some way also an abstraction layer for the
hypervisors, so in a sense a libvirt driver for OpenNebula
is a bit 'redundant' ? Maybe i didn't understood well the
principles behind OpenNebula :-) (sorry first time I learn about
this).
Yes you are right, OpenNebula provides an abstraction layer for A SET of
distributed resources (like Platform VM Orchestrator or VMWare DRS). In this
way, OpenNebula leverages the functionality provided by the underlying VM
hypervisors to provide a centralized management (allocation and re/allocation
of VMs, balance of workload....) of a pool physical resources.
The libvirt API is just another interface to the OpenNebula system. The beauty
is that you can manage a whole cluster of hypervisors using the libvirt
standard, i.e. in the same way you interact with a single machine.
For example, oVirt uses libvirt to interact with the physical nodes. With
OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole
cluster. In this case you could use the great interface from oVirt to manage
several clusters. And you could abstract those applications from the details
of managing the cluster (for example, is there NFS in it?, group/user
policies...)
Finally, and may be adding more confusion, OpenNebula also uses libvirt
underneath to interface with some of the hypervisors of the physical nodes
(e.g. KVM).
- what is the future of that patch ? Basically libvirt internals
changes extremely fast, so unless a driver gets included as part
of libvirt own code source, there is a lot of maintainance and
usability problems resulting from the split. Do you intent to
submit it for inclusion, or is that more a trial to gauge interest ?
Submitting the driver for inclusion means the code will have to be
reviewed, released under LGPL, and a voluteer should be available
for future maintainance and integration issues.
Yes we are highly interested in contributing the driver. We have no problems
with the requirements and we can commit resources to maintain and integrate
the driver. Please let me know how we should proceed...
thanks !
Daniel
Cheers
Ruben
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
10:59 a.m.
On Mon, Nov 03, 2008 at 05:26:34PM +0100, Ruben S. Montero wrote:
Hi Daniel
On Monday 03 November 2008 16:43:32 Daniel Veillard wrote:
>
> Interesting, but this raises a couple of questions:
> - isn't OpenNebula in some way also an abstraction layer for the
> hypervisors, so in a sense a libvirt driver for OpenNebula
> is a bit 'redundant' ? Maybe i didn't understood well the
> principles behind OpenNebula :-) (sorry first time I learn about
> this).
Yes you are right, OpenNebula provides an abstraction layer for A SET of
distributed resources (like Platform VM Orchestrator or VMWare DRS). In this
way, OpenNebula leverages the functionality provided by the underlying VM
hypervisors to provide a centralized management (allocation and re/allocation
of VMs, balance of workload....) of a pool physical resources.
The libvirt API is just another interface to the OpenNebula system. The beauty
is that you can manage a whole cluster of hypervisors using the libvirt
standard, i.e. in the same way you interact with a single machine.
After further reading, yes I understand, it's the reverse appraoch
from ovirt, where we use libvirt to build the distributed management.
One interesting point is that your driver would allow to access EC2
using libvirt APIS...
For example, oVirt uses libvirt to interact with the physical nodes.
With
OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole
cluster. In this case you could use the great interface from oVirt to manage
several clusters. And you could abstract those applications from the details
of managing the cluster (for example, is there NFS in it?, group/user
policies...)
This is a bit against the Node principle of libvirt, and could result
in some fun in the hardware discovery mode, but in general the approach
might work. Still we are looking at bits on the node to provide
capabilities of the hypervisor, which may break in your case, and
migration is defined as an operation between a domain in a given node
and a connection to another node, so the migration within the OpenNebula
cluster won't be expressable in a simple way with the normal libvirt
API. Except that things should work conceptually I think.
Finally, and may be adding more confusion, OpenNebula also uses
libvirt
underneath to interface with some of the hypervisors of the physical nodes
(e.g. KVM).
Ouch :-) okay !
> - what is the future of that patch ? Basically libvirt
internals
> changes extremely fast, so unless a driver gets included as part
> of libvirt own code source, there is a lot of maintainance and
> usability problems resulting from the split. Do you intent to
> submit it for inclusion, or is that more a trial to gauge interest ?
> Submitting the driver for inclusion means the code will have to be
> reviewed, released under LGPL, and a voluteer should be available
> for future maintainance and integration issues.
Yes we are highly interested in contributing the driver. We have no problems
with the requirements and we can commit resources to maintain and integrate
the driver. Please let me know how we should proceed...
Well well well ...
Basically the contributtion should be provided as a (set of) patch(es)
agaisnt libvirt CVS head. Preferably the code should follow the existing
coding guidelines of libvirt, reuse the existing infrastructure for
error, memory allocations, etc ... If "make check syntax-check' compiles
cleanly with your code applied that's a good first start :-)
In general the inclusion takes a few iteration of reviews before being
pushed, and splitting patches into smaller chunks helps the review
process greatly.
I didn't yet took the time to look at the patch online, so I have no
idea a-priori of the work needed. Drivers are usually clean and
separate, the problem is have them in the code base to minimize
maintainance.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
1:32 p.m.
On Monday 03 November 2008 17:59:33 Daniel Veillard wrote:
This is a bit against the Node principle of libvirt, and could result
in some fun in the hardware discovery mode, but in general the approach
might work. Still we are looking at bits on the node to provide
capabilities of the hypervisor, which may break in your case, and
migration is defined as an operation between a domain in a given node
and a connection to another node, so the migration within the OpenNebula
cluster won't be expressable in a simple way with the normal libvirt
API. Except that things should work conceptually I think.
You are totally right, this is putting the standard to the limit ;). There are
some function calls that can not be implemented right away or, as you said,
the semantics are slightly different. Maybe there is room to extend the API in
the future, right now there is no standard way to interface a distributed VM
Manager....
Basically the contributtion should be provided as a (set of)
patch(es)
agaisnt libvirt CVS head. Preferably the code should follow the existing
coding guidelines of libvirt, reuse the existing infrastructure for
error, memory allocations, etc ... If "make check syntax-check' compiles
cleanly with your code applied that's a good first start :-)
In general the inclusion takes a few iteration of reviews before being
pushed, and splitting patches into smaller chunks helps the review
process greatly.
I didn't yet took the time to look at the patch online, so I have no
idea a-priori of the work needed. Drivers are usually clean and
separate, the problem is have them in the code base to minimize
maintainance.
Ok. It sounds fine. We will update our implementation to CVS head (right now
the patch is targeted for 0.4.4), update licenses to LGPL, and we will check
if 'make check syntax-check' works. Also We'll try to split the patch in
self-
contained changes, so they are easy to review. I'll let you know when we are
done...
Cheers
Ruben
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
5:29 p.m.
On Mon, Nov 03, 2008 at 08:32:54PM +0100, Ruben S. Montero wrote:
On Monday 03 November 2008 17:59:33 Daniel Veillard wrote:
>
> This is a bit against the Node principle of libvirt, and could result
> in some fun in the hardware discovery mode, but in general the approach
> might work. Still we are looking at bits on the node to provide
> capabilities of the hypervisor, which may break in your case, and
> migration is defined as an operation between a domain in a given node
> and a connection to another node, so the migration within the OpenNebula
> cluster won't be expressable in a simple way with the normal libvirt
> API. Except that things should work conceptually I think.
You are totally right, this is putting the standard to the limit ;). There are
some function calls that can not be implemented right away or, as you said,
the semantics are slightly different. Maybe there is room to extend the API in
the future, right now there is no standard way to interface a distributed VM
Manager....
This is a really interesting problem to figure out. We might like to
extend the node capabilities XML to provide information about the
cluster as a whole - we currently have <guest> element describing
what guest virt types are supported by a HV connection, and a <host>
element describing a little about the host running the HV. It might
make sense to say that the <host> info is optional and in its place
provide some kind of 'cluster' / 'host group' information. I won't
try to suggest what now - we'll likely learn about what would be
useful through real world use of your initial driver functionality.
> Basically the contributtion should be provided as a (set of)
patch(es)
> agaisnt libvirt CVS head. Preferably the code should follow the existing
> coding guidelines of libvirt, reuse the existing infrastructure for
> error, memory allocations, etc ... If "make check syntax-check' compiles
> cleanly with your code applied that's a good first start :-)
> In general the inclusion takes a few iteration of reviews before being
> pushed, and splitting patches into smaller chunks helps the review
> process greatly.
> I didn't yet took the time to look at the patch online, so I have no
> idea a-priori of the work needed. Drivers are usually clean and
> separate, the problem is have them in the code base to minimize
> maintainance.
>
Ok. It sounds fine. We will update our implementation to CVS head (right now
the patch is targeted for 0.4.4), update licenses to LGPL, and we will check
if 'make check syntax-check' works. Also We'll try to split the patch in
self-
contained changes, so they are easy to review. I'll let you know when we are
done...
When you update to work with latest CVS, I'd strongly recommend you make
use of the brand new XML handling APIs we have in domain_conf.h. We have
switched all drivers over to use these shared internal APIs for parsing
the domain XML schema, so it would let you delete 90% of your one_conf.c
file.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5:39 p.m.
Daniel P. Berrange wrote:
When you update to work with latest CVS, I'd strongly recommend
you make
use of the brand new XML handling APIs we have in domain_conf.h. We have
switched all drivers over to use these shared internal APIs for parsing
the domain XML schema, so it would let you delete 90% of your one_conf.c
file.
It is great(!) to see that someone actually started to care about this;
but honestly requests for these things were before blundly rejected.
See: Comfortable lookup functions interface/block stats
Could someone elaborate why after 5 months I can tag this project as
'suddenbreakoutofcommonsense'?
Stefan
3:45 a.m.
On Tue, Nov 04, 2008 at 12:39:11AM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
>When you update to work with latest CVS, I'd strongly recommend you make
>use of the brand new XML handling APIs we have in domain_conf.h. We have
>switched all drivers over to use these shared internal APIs for parsing
>the domain XML schema, so it would let you delete 90% of your one_conf.c
>file.
It is great(!) to see that someone actually started to care about this;
but honestly requests for these things were before blundly rejected.
If you look at the mailing list archives you'll find this generic domain
XML api was a long standing item on our TODO list. We had been planning
to implenent & working towards it over time.
Could someone elaborate why after 5 months I can tag this project as
'suddenbreakoutofcommonsense'?
If you want to be a troll please go elsewhere.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:04 a.m.
Last time *your* argument was that the API would get too big. Now why
isn't that argument valid anymore? I'm honestly asking for an
explanation on this point, and I do expect you have it.
Stefan
10:10 a.m.
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
Last time *your* argument was that the API would get too big. Now why
isn't that argument valid anymore? I'm honestly asking for an
explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has
scalability issues because it is a long term supported ABI. The internal
API size is irrelevant because we can & will change that at will. The
domain XML handling API is internal only for in-tree drivers. So there
has been no change in policy wrt to the external API
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:21 a.m.
Daniel P. Berrange wrote:
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
> Last time *your* argument was that the API would get too big. Now why
> isn't that argument valid anymore? I'm honestly asking for an
> explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has
scalability issues because it is a long term supported ABI. The internal
API size is irrelevant because we can & will change that at will. The
domain XML handling API is internal only for in-tree drivers. So there
has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C
perspective?) or isn't this code exported to the shared library?
Stefan
ps. Sorry if you thought I was trying to virtualize a troll.
10:26 a.m.
As part of the internal API (and not explicitly exported from src/libvirt_sym.version) The
xml parsing would not be available to external apps.
Stefan de Konink wrote on 11/04/2008 11:21 AM:
Daniel P. Berrange wrote:
> On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
>> Last time *your* argument was that the API would get too big. Now why
>> isn't that argument valid anymore? I'm honestly asking for an
>> explanation on this point, and I do expect you have it.
>
> You are confusing internal API with external API. The external API has
> scalability issues because it is a long term supported ABI. The internal
> API size is irrelevant because we can & will change that at will. The
> domain XML handling API is internal only for in-tree drivers. So there
> has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C
perspective?) or isn't this code exported to the shared library?
Stefan
ps. Sorry if you thought I was trying to virtualize a troll.
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
10:29 a.m.
On Tue, Nov 04, 2008 at 05:21:50PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
>On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
>>Last time *your* argument was that the API would get too big. Now why
>>isn't that argument valid anymore? I'm honestly asking for an
>>explanation on this point, and I do expect you have it.
>
>You are confusing internal API with external API. The external API has
>scalability issues because it is a long term supported ABI. The internal
>API size is irrelevant because we can & will change that at will. The
>domain XML handling API is internal only for in-tree drivers. So there
>has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C
perspective?) or isn't this code exported to the shared library?
No, the internal APIs are only intended for use by code that is part of
libvirt source tree. While some of the internal APIs may appear in the
shared library, they are strictly for private use by the libvirtd daemon
because we can make no guarentee that they will work across even bug-fix
releases of libvirt. We are working on enforcing the privacy of internal
APIs using better linker scripts to control symbol visibility.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5:44 p.m.
Hi Daniel,
Thanks very much for your suggestions, the new version of the driver will make
use of the new XML handing API. Regarding the use of a 'cluster' or 'host
group' element we'll make a summary of the limitations we found when dealing
with a cluster, so you can have a clear view.
Cheers
Ruben
On Tuesday 04 November 2008 00:29:09 Daniel P. Berrange wrote:
On Mon, Nov 03, 2008 at 08:32:54PM +0100, Ruben S. Montero wrote:
> On Monday 03 November 2008 17:59:33 Daniel Veillard wrote:
> > This is a bit against the Node principle of libvirt, and could result
> > in some fun in the hardware discovery mode, but in general the approach
> > might work. Still we are looking at bits on the node to provide
> > capabilities of the hypervisor, which may break in your case, and
> > migration is defined as an operation between a domain in a given node
> > and a connection to another node, so the migration within the
> > OpenNebula cluster won't be expressable in a simple way with the normal
> > libvirt API. Except that things should work conceptually I think.
>
> You are totally right, this is putting the standard to the limit ;).
> There are some function calls that can not be implemented right away or,
> as you said, the semantics are slightly different. Maybe there is room to
> extend the API in the future, right now there is no standard way to
> interface a distributed VM Manager....
This is a really interesting problem to figure out. We might like to
extend the node capabilities XML to provide information about the
cluster as a whole - we currently have <guest> element describing
what guest virt types are supported by a HV connection, and a <host>
element describing a little about the host running the HV. It might
make sense to say that the <host> info is optional and in its place
provide some kind of 'cluster' / 'host group' information. I won't
try to suggest what now - we'll likely learn about what would be
useful through real world use of your initial driver functionality.
> > Basically the contributtion should be provided as a (set of) patch(es)
> > agaisnt libvirt CVS head. Preferably the code should follow the
> > existing coding guidelines of libvirt, reuse the existing
> > infrastructure for error, memory allocations, etc ... If "make check
> > syntax-check' compiles cleanly with your code applied that's a good
> > first start :-)
> > In general the inclusion takes a few iteration of reviews before being
> > pushed, and splitting patches into smaller chunks helps the review
> > process greatly.
> > I didn't yet took the time to look at the patch online, so I have no
> > idea a-priori of the work needed. Drivers are usually clean and
> > separate, the problem is have them in the code base to minimize
> > maintainance.
>
> Ok. It sounds fine. We will update our implementation to CVS head (right
> now the patch is targeted for 0.4.4), update licenses to LGPL, and we
> will check if 'make check syntax-check' works. Also We'll try to split
> the patch in self- contained changes, so they are easy to review. I'll
> let you know when we are done...
When you update to work with latest CVS, I'd strongly recommend you make
use of the brand new XML handling APIs we have in domain_conf.h. We have
switched all drivers over to use these shared internal APIs for parsing
the domain XML schema, so it would let you delete 90% of your one_conf.c
file.
Regards,
Daniel
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
2:12 a.m.
On Mon, Nov 03, 2008 at 08:32:54PM +0100, Ruben S. Montero wrote:
On Monday 03 November 2008 17:59:33 Daniel Veillard wrote:
>
> This is a bit against the Node principle of libvirt, and could result
> in some fun in the hardware discovery mode, but in general the approach
> might work. Still we are looking at bits on the node to provide
> capabilities of the hypervisor, which may break in your case, and
> migration is defined as an operation between a domain in a given node
> and a connection to another node, so the migration within the OpenNebula
> cluster won't be expressable in a simple way with the normal libvirt
> API. Except that things should work conceptually I think.
You are totally right, this is putting the standard to the limit ;). There are
some function calls that can not be implemented right away or, as you said,
the semantics are slightly different. Maybe there is room to extend the API in
the future, right now there is no standard way to interface a distributed VM
Manager....
As Dan expressed too, that's not a blocker, we can find ways to
increase the APIs or the expressiveness of the XML descriptions used.
But it's not urgent, the basic operations can be implemented without
this.
Ok. It sounds fine. We will update our implementation to CVS head
(right now
the patch is targeted for 0.4.4), update licenses to LGPL, and we will check
if 'make check syntax-check' works. Also We'll try to split the patch in
self-
contained changes, so they are easy to review. I'll let you know when we are
done...
Cool. In a sense there is no real hurry, I would like to make the
0.5.0 release probably end of next week, and we have much to review and
check before that, if your patches could arrive shortly after the 0.5.0
release that would be a nice time to integrate them. Of course earlier
patch are not a problem but we will probably have less time to review
them considering the things started but not finished for 0.5.0 :-)
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:21 p.m.
On Tuesday 04 November 2008 09:12:00 Daniel Veillard wrote:
> Ok. It sounds fine. We will update our implementation to CVS head (right
> now the patch is targeted for 0.4.4), update licenses to LGPL, and we
> will check if 'make check syntax-check' works. Also We'll try to split
> the patch in self- contained changes, so they are easy to review. I'll
> let you know when we are done...
Cool. In a sense there is no real hurry, I would like to make the
0.5.0 release probably end of next week, and we have much to review and
check before that, if your patches could arrive shortly after the 0.5.0
release that would be a nice time to integrate them. Of course earlier
patch are not a problem but we will probably have less time to review
them considering the things started but not finished for 0.5.0 :-)
thanks !
Daniel
Great, It make sense we'll target the new version of our driver for the
0.5.0
version.
Good luck with 0.5.0!!
Cheers
Ruben
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
5862
days inactive
5863
days old
15 comments
5 participants
participants (5)
-
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard -
Ruben S. Montero -
Stefan de Konink