Helo Daniel,

 

thanks for the initial tips. I have submitted a new (more personal) email so within a few days all should be settled.

 

To the feedback. I did not expect anything less than a request for a batch of smaller git patches. My first post here was merely to raise some public awareness of the driver and this seemed like a logical place where the information should go. I also wanted to know if I should even try to do the preparatory work for the patches considering there is already another OpenVZ driver included in libvirt.

 

I will try to prepare some initial patches next week or so to test the proper way the code should flow upstream.

 

--

David Fabian

Cluster Desgin, s.r.o.

 

Dne Po 30. června 2014 11:51:20, Daniel Veillard napsal(a):

> On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote:

> > Hello,

>

> Hello,

>

> first small rule here, trust is build on persons like most open source

> projects, so please change your email, I want to communicate with a person

> not with the name of a company.

>

> > in the company I work for, we use openvz and qemu/kvm on our clusters

> > side-by-side. To manage our domains, we used libvirt/qemu for qemu/kvm

> > domains and vz tools for openvz domains in the past. This was very

> > inconvinient since the management differed in many ways. So we have

> > decided to unify our management and use libvirt exclusively. Since the

> > openvz driver already included in libvirt lacks features that need,

> > we have implemented a new libvirt backend driver for openvz called the

> > bossonvz driver.

>

> it's true that the openvz diver is lagging behind a bit, I didn't see

> any real update since 2012. That wouldn't be the first time that we have

> multiple drivers for a given hypervisor, Xen is a precedent at least,

> though that's not a perfect situation as it dilutes manpower to maintain

> drivers for the hypervisor.

>

> > Unlike the openvz driver, bossonvz is a complete, feature-rich

> > stateful libvirt driver. It uses the libvirt driver API exclusively and

> > communicates with the kernel directly, much like the LXC driver. The

> > code is hugely inspired by the LXC driver and the Qemu driver, but adds

> > a bit of functionality to the libvirt core too. More details and the

> > source code can be found at

> >

> > http://bossonvz.bosson.eu/

> >

> > The driver is completely independent of vz tools, it needs only a running vz kernel. One of the things, we are most proud of, is the possibility to access the domain's tty via VNC (hurray to uniform management web interfaces).

> >

> > Since the code was developed in-house (primarily for internal purposes),

> > it is based on an older libvirt release (1.1.2). There are also some

> > modifications to the libvirt core (virCommand) and the domain file

> > (mount options syntax) which might need some redesign.

> >

> > At the moment I would like to get some feedback on the driver. In the future, I would like to see the driver merged upstream, and am prepared to do the work but I need to know if there is any interest in doing so.

>

> The proper way to get feedback on the driver is:

> 1/ rebase your code to the current version, there is nothing we

> can do with a patch for 1.1.2

> 2/ split the changes logically, nobody will review a 44312 line

> patch, remove garbage from diffing generated files like configure

> 3/ submit the patches on this list for review, each patch having

> details about what it does, etc ... best manage all this with

> git on a branch from the upstream or you will be mad very quickly

> see how other does, that's standard practice and if you're not

> familiar with it, learning it won't be a lot time really.

> 4/ you will need to add patches adding documentation, no doc, no

> upstream :)

>

> If you think it's too much, then don't bother because we will need

> commitment to maintaining the driver over the years, and the sum of

> the work will be even larger than those initial steps. What you gain

> in exchange is integration in upstream, easier maintainance, easier

> rebase and recognition in the community.

>

> Makes sense ?

>

> Daniel

>

>