Fair enough. We have no problem to adapt to the new process. I don't know how libcontainer is designed internally and how low-level it is but having a thin user-space wrapper around the vzkernel would be wonderful. I wanted to use libvzctl in bossonvz to abstract the driver away from the low-level stuff but the library is just too much interconnected with the veconf parser.
The current vz kernel API is not the nicest thing to work with to be honest and a shared user-space library would help both vzctl and bossonvz. If you are interested in my POV on the kernel API, I would say you should leave more work for the user-space. At the moment, when the user-space asks for a new container, the vzkernel magically creates a new environment and sets everything (esp. cgroups) by itself without any chance for the user-space to set anything. Because libvirt has its own cgroup hierarchy model and any libvirt driver should honor it, bossonvz should, idealy, create cgroups for the container under the libvirt hierarchy but it cannot since the kernel won't let it.
As I see it, the driver has to do two separate things to successfully use the kernel API. There are the vz specific syscalls/ioctls (e.g. VZCTL_ENV_CREATE_DATA) and there is a preparatory work done in the user-space (preparing forked sub-processes, pipes, etc.). Is the new SDK going to cover only the low-level code (ioctls) or will I be able to use some sort of a high-level function like spawn_environment() and get PID of the newly created container's init?
The amount of vz specific code in the bossonvz driver is not that big. The ioctls is just a single bossonvz_environment.c file. The harder part is the preparatory part which is located in bossonvz_container.c and is quite complex since it closely mimics the code path of vzctl (otherwise the driver would not work).
--
David Fabian
Cluster Design, s.r.o.
Dne St 2. července 2014 19:41:15, Pavel Emelyanov napsal(a):
> On 07/02/2014 04:15 PM, Bosson VZ wrote:
> > Thanks in return for the acknowledgement.
> >
> >
> >
> > I understand that the long-term plan is to reduce the size of the vzkernel patch and to
> > only use vanilla kernel primitives Daniel was talking about. That would be an ideal situation.
>
> Yes, at the kernel level the long term plan is to eventually
> get rid of vz-specific API and switch to namespaces/cgroups
> completely. Thus any new users that sit on the vzkernel API
> make this process ... harder :)
>
> > The thing is that we simply cannot wait for this merge to happen. We have been using OpenVZ
> > for many years and bossonvz is just a convenient tool for us right now and, at least, in the
> > mid-term future. My question is how is the new libcontainer/PCS SDK library going to influence
> > the existing vz-tools eco-system?
>
> We will keep the CLI (vzctl) and library (libvzctl) working on
> new OpenVZ installations for some time (several years, I suppose)
> by making them properly redirect calls to new API.
>
> But all the new features will be implemented within the new API,
> libcontainer/PCS SDK.
>
> Thanks,
> Pavel
>