On 03/24/2015 12:48 AM, Pavel Snajdr wrote: > On 03/23/2015 11:01 PM, Kir Kolyshkin wrote: >> >> >> On 03/23/2015 03:12 AM, Benjamin Henrion wrote: >>> On Mon, Mar 23, 2015 at 10:55 AM, Narcis Garcia >>> <informat...@actiu.net> wrote: >>>> As I read from Ubuntu/Debian package (version 0.9.1): >>>> >>>> Docker complements kernel namespacing with a high-level API which >>>> operates at the process level. It runs unix processes with strong >>>> guarantees of isolation and repeatability across servers. >>>> >>>> Docker is a great building block for automating distributed systems: >>>> large-scale web deployments, database clusters, continuous deployment >>>> systems, private PaaS, service-oriented architectures, etc. >>>> >>>> This package contains the daemon and client. *Using docker.io on >>>> non-amd64 hosts is not supported at this time*. Please be careful when >>>> using it on anything besides amd64. >>>> >>>> Also, note that *kernel version 3.8 or above is required* for proper >>>> operation of the daemon process, and that any lower versions may have >>>> subtle and/or glaring issues. >>> Redhat backported a lot of LXC features to 2.6.32, so that's one of >>> the reasons you can run docker/lxc on top of the openvz kernel. >> >> In addition to that, we did a significant amount of kernel work >> to allow running Docker inside our containers. >> >> In general, OpenVZ kernel version (which is 2.6.32) has very little >> to do with vanilla 2.6.32, so this number doesn't really mean anything >> except that Red Hat kernel team branched their kernel off this >> version when they started working on RHEL6. >> >> Currently this is 2.6.32 plus tons of patches from Red Hat plus >> a pretty big patchset from OpenVZ. In particular, we make sure all the >> recent distros work inside containers, so sometimes we have to backport >> some new syscall or other feature from recent kernels. >> >> From time to time I see people saying OpenVZ kernel is very old and >> obsoleted. It happens because the judge by the label, and the label starts >> with 2.6.32. Indeed, 2.6.32 is a very old kernel, but as I explained above >> our kernel has very little to do with 2.6.32. > > Hi Kir, > > I've been telling those people just about the same thing, but recently I > don't think I can agree. I've become more involved in ZFS on Linux > development and we run on RHEL6 OpenVZ kernel. The core of RHEL6 is > getting old and there are lots and lots of improvement, that have gone > upstream, which improve mainly performance and multi-core scalability. > For instance and probably the most importantly for me now, I would like > to have VFS scalability patches, that have gone into upstream, in OpenVZ > RHEL6 kernel as well, as I'd like to see doing more granular eviction on > dentries. (http://lwn.net/Articles/636133/)
Sorry, linked the wrong thing, I mean two separate things. Primary objective is to have the shrinker work, which has gone to 3.12, secondary and nice to have would be these VFS scalability patches. > > But this seems rather impossible, due to git/separated-out-patches not > being available for RHEL6 kernel and OpenVZ project following the suit. > I would have to invest a lot of time every time a rebase onto a newer > RHEL6 kernel release is made. > > I would like to help out with OpenVZ development from time to time, > especially with things related to storage, but the project doesn't seem > all that open, you guys only publish your final results, but nothing > from the process of getting to them. > > I don't mean to criticize or I don't mean it in any other bad way, > here's me just sighing at how things are. Do you see any room for change > in this regard? Or should we just leverage Parallels paid support for > OpenVZ to have you guys pull in the patches by yourselves? > > I love open-source and doing things openly, I know that you guys don't > have a whole lot of breathing room thanks to Red Hat here, but is there > any possibility of opening the project up more? > > Finally, I would like to thank all of you at the OpenVZ project, there > is no other usable container technology for Linux without you guys. I > highly respect that fact despite the relative closedness of the project. > > /snajpa > (vpsFree.cz) > >> _______________________________________________ >> Users mailing list >> Users@openvz.org >> https://lists.openvz.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
