Разработчики проекта OpenVZ сдержали все свои обещания (https://www.opennet.me/opennews/art.shtml?num=41350) и выпустили финальную версию OpenVZ 7.0 (https://openvz.org), продукта, образованного в результате слияния кодовых баз открытой системы контейнерной виртуализации OpenVZ и коммерческого продукта Virtuozzo (Parallels Cloud Server). Теперь все желающие получили возможность промышленного использования последней версии контейнеров OpenVZ. Исходный код новой версии полностью открыт и доступен в публичном репозитории (https://src.openvz.org/projects/OVZ) и зеркале на GitHub (https://github.com/openvz).
Основные изменения по сравнению с предыдущей версией OpenVZ, базирующейся на ядрах 2.6.32 и 2.6.18:- Новая версия OpenVZ представляет собой законченное решение для виртуализации и предлагается в виде Linux дистрибутива, готового для установки на "голое" железо. Для этой версии не предоставляется поддержка установки компонентов OpenVZ поверх других дистрибутивов. По крайней мере на данный момент. Но так как код всех компонентов OpenVZ открыт под лицензией GPL или совместимыми, то нет никаких помех для портирования необходимых компонентов на другой дистрибутив, если у кого-то возникнет такая потребность. Для контактов с командой разработки предлагается использовать список рассылки devel@openvz.org;
- Linux ядро базируется на последней версии ядра от Red Hat - RHEL 7 (https://access.redhat.com/articles/3078) (версия соответствует ядру 3.10+). Размер патча по сравнению с ядрами RHEL5, RHEL6 был существенно уменьшен, чего удалось достичь за счет активного использования штатных технологий, уже включённых в состав основной ветки ядра Linux;- Добавлено online-управление памятью контейнеров и виртуальных машин, реализованное с помощью подсистемы memory cgroups, предоставляемой ядром Linux, и сервиса vcmmd;
- Гарантированные ограничения памяти для виртуальных машин и контейнеров;
- Функциональность для более эффективного использования оперативной памяти, доступной на физическом сервере: KSM (kernel same-page merging);
- Проприетарный гипервизор Parallels был заменён на гипервизор KVM/QEMU;
- Добавлена возможность интеграции с LibVirt (https://www.opennet.me/opennews/art.shtml?num=44765) с помощью отдельного драйвера virtuozzo (https://libvirt.org/drvvirtuozzo.html). Драйвер позволяет управлять контейнерами и виртуальными машинами OpenVZ с помощью стандартных утилит virsh, virt-install, GUI оболочку virt-manager (https://kb.virtuozzo.com/en/129047) и других приложений, интегрированных с LibVirt (http://libvirt.org/apps.html). Все изменения, необходимые для Virtuozzo, были приняты в основную ветку проекта LibVirt. Помимо LibVirt API в OpenVZ 7.0 появилась возможность применения storage pools (https://libvirt.org/storage.html), что позволит использовать не только ploop и simfs, но и другие бэкенды хранения данных для контейнеров;
- "Живая" миграция для контейнеров реализована с помощью инструментария CRIU (https://www.opennet.me/opennews/art.shtml?num=44015) и P.Haul (https://www.opennet.me/opennews/art.shtml?num=42850) вместо использования кода "заморозки"/"разморозки" процессов, реализованного в предыдущих версиях OpenVZ в ядре vzkernel;
- Упрощена возможность обновления с бесплатной версии OpenVZ на платную - достаточно установить дополнительные пакеты и активировать лицензию;
- Для новой версии доступна полноценная документация на сайте docs.openvz.org (https://docs.openvz.org/);
- Переход на использование EZ-шаблонов для контейнеров, что позволит облегчить управление шаблонами на серверах с OpenVZ. Для управления шаблонами предлагается использовать утилиту vzpkg (https://docs.openvz.org/virtuozzo_7_command_line_reference.w...).
- Для OpenVZ 7.0 доступна интеграция с OpenStack (https://openvz.org/Setup_OpenStack_with_Virtuozzo_7).
До сих пор в предыдущих версиях OpenVZ и коммерческом продукте Virtuozzo утилита vzctl разрабатывалась независимо. В OpenVZ/Virtuozzo 7.0 было решено оставить версию из коммерческого продукта, поэтому совместимость vzctl была нарушена. Для управления контейнерами и виртуальными машинами рекомендуется использовать утилиту prlctl. Для начала работы с новой утилитой можно воспользоваться "шпаргалку" (https://bronevichok.ru/trash/openvz-7-cheatsheet.pdf) с синтаксисом популярных команд. В последующих версиях планируется отказаться от утилиты vzctl и использовать prlctl как основную утилиту.
Для установки OpenVZ 7.0 доступен установочный образ, который можно загрузить с одного из основных серверов OpenVZ или с одного из зеркал проекта (http://mirrors.openvz.org/). Также опубликован скрипт (https://lists.openvz.org/pipermail/users/2015-July/006313.html) для облегчения миграции контейнеров с предыдущей версии OpenVZ на OpenVZ 7.0.URL: https://lists.openvz.org/pipermail/announce/2016-July/000664...
Новость: http://www.opennet.me/opennews/art.shtml?num=44848
"Жадный хостер 7.0"
не в бровь, а в глаз (ц)
оно кроме как обнаглевшим хостерам с копеечными "VPS-ками" и феерическими OOM-ами сплошь и рядом уже никому увы не нужно,
поезд ушёл, пять лет назад открывать код надо было,
а теперь есть богомерзкий докер и прочие lxc для приложений и нормальная полная виртуализация kvm/xen + всякие вмтвари и прочие сферические виртуалбоксы
Собственно, потому и закопошились :-)
Открытие кода в виде OpenVZ произошло не 5, а целых 11 лет назад. Сюрприз?
Docker и lxc не являются полноценной заменой openvz, нет нужного уровня изоляции.
Если лично ты не придумал как использовать OpenVZ/Virtuozzo за пределами "жадного хостинга", то это не их недостаток, а твоя некомпетентность.
kvm/vmmanager вполне работают
это в опенвз-то изоляция?
Работаю в очень жадном хостере, изоляция есть, зависимости нет, брат жив. Обоснуй скептицизм или нутыпонел...
> Работаю в очень жадном хостере, изоляция есть, зависимости нет, брат жив. Обоснуй
> скептицизм или нутыпонел...Рынок тебе обоснует. Двухбаксовыми KVM VPS у янки.
Где где?
> Где где?Франция/Канада 2.99 евро: https://www.ovh.ie/vps/vps-ssd.xml
> Франция/Канада 2.99 евро: https://www.ovh.ie/vps/vps-ssd.xmlДа их таких каждый второй сейчас.
Но openvz все же дешевле, 90руб: https://firstvds.ru/products/vds_vps_cheap
> Но openvz все же дешевле, 90руб: https://firstvds.ru/products/vds_vps_cheapFirstVDS - замечательная компания. Чтобы советовать врагам и конкурентам. Всего 90 рублей в месяц, а столько геморроя!!! :) Самый падучий хостер их всех виденных, с наглым и некомпетентным саппортом. Да еще в рунете, где всегда можно нарваться на беспредел государства и роскомнадзор, охреневший настолько что блокируют даже транзитный траффик.
> FirstVDS - замечательная компания. Чтобы советовать врагам и конкурентам. Всего 90 рублей
> в месяц, а столько геморроя!!! :)Именно. Эти нетрадиционной ориентации товарищи пытались с меня взять денег за закрытие уязвимости в ОС (о котором сами же сообщили в своей рассылке). Точнее, как: в старом кластере у них старье, в новый можно перенести без сохранения IP, а за перенос IP - башляй.
Я, конечно, сам пропатчил ручками и пересобрал на том, что было. И поскорее унес все оттуда подальше.
Они пытаются брать денег за все, даже за свои факапы (!!!). Но платить не за что: саппорт наглое школьё. Сейчас они честно дописали что за работоспособность фигни за 90 рублей ответственности не несут. На практике это означает падучие сервера и враждебный саппорт. Чтобы совсем хорошо, в случае OpenVZ админ контейнера может справиться далеко не с любыми проблемами, результат - полное попадалово. Потребовался модуль айпитаблеса? Изволь доплатить. За особенности их же технологий.
Я не то чтобы их рекламировать хочу, репутация мне известна - для нормального проекта наверно действительно нужно что получше, но с другой стороны на старой vps у меня у них аптайм был больше года, хотя он мне нужен только как dns slave, ssh proxy и nginx для своего барахла.Недавно перенес все на новый, чтобы debian был не такой протухший.
Ясное дело, что если вам нужно свое ядро с преферансом и куртизанками, то берете что-то другое.
Парадокс в том что буржуи относятся к клиенту как к клиенту даже за 2 бакса. Сервера не падают, сеть не лагает, саппорт не хамит. А FirstVDS всем своим видом показывает что они делают мне великое одолжение что вообще изволят меня хостить. А технические проблемы и ограничения их технологий дележа ресурсов мигом превращаются в проблемы клиента. Сам ты нужный модуль не вгрузишь, а все что требует общения с саппортом в FirstVDS - хуже фильма ужасов. Поэтому, если вопрос встает ребром - можно даже и переплатить полдоллара в месяц за нормальный саппорт и технологию виртуализации которая не трансформируется при случае в проблему клиента.
>> двухбаксовыми
> 2.99 евроКажется, пока есть разница.
arubacloud - 1 евро. Вмварь, гиг памяти. Места, правда, жалкие 20 гигов, зато SSD.
> это в опенвз-то изоляция?да.
PS: орлам, вопящим про lxc, остаётся предложить для начала поинтересоваться, с какого дуба вообще эти жёлуди...
а сколько лет назад произошло закрытие кода - после того как сообществу дали поиграться?..
напомню это было во время 2.4.18.
Где гарантия что не закроют еще раз?
> Открытие кода в виде OpenVZ произошло не 5, а целых 11 лет
> назад. Сюрприз?
> Docker и lxc не являются полноценной заменой openvz, нет нужного уровня изоляции.
> Если лично ты не придумал как использовать OpenVZ/Virtuozzo за пределами "жадного хостинга",
> то это не их недостаток, а твоя некомпетентность.Давай не будем рассказывать сказки. Разница OpenVZ и всякого LXC отличается в паре тройке лимитов - которые вы вынуждены заливать в ядро, ибо ресурсов на свою разработку нету. Достаточно посмотреть на стиль разработки в git, что бы понять - что в датском королевстве что-то не ладно.
Virtuozzo это давно уже не только контейнеры. Мы делаем полноценный продукт для виртуализации вместе с системой хранения данных и отказоустойчивостью.Если вы пробовали Virtuozzo/OpenVZ 7 и LXC и для вас разница только в паре-тройке лимитов ну ок. Значит у вас такие скудные требования. Остальным советую взглянуть на сравнение https://openvz.org/Comparison
> Virtuozzo это давно уже не только контейнеры. Мы делаем полноценный продукт для
> виртуализации вместе с системой хранения данных и отказоустойчивостью.Если ваш субпродукт будет треобвать плясок с вашими местными ядрами - вас ждут самые радостные перспективы, о которых вы уже начинаете догадываться.
>> Virtuozzo это давно уже не только контейнеры. Мы делаем полноценный продукт для
>> виртуализации вместе с системой хранения данных и отказоустойчивостью.
> Если ваш субпродукт будет треобвать плясок с вашими местными ядрами - вас
> ждут самые радостные перспективы, о которых вы уже начинаете догадываться.А другие компании, которые делают свой продукт на базе Linux, вы тоже предупредили о том, что их ждет? Мы c 2006 года (https://openvz.org/History#2006) делаем продукт на базе модифицированного ядра от Red Hat, у нас всё хорошо, клиенты довольны. А про успешные случаи монетизации LXC я пока не слышал.
> А другие компании, которые делают свой продукт на базе Linux, вы тоже
> предупредили о том, что их ждет?Я даже и не могу вспомнить других компаний занимающихся виртуализацией или контейнерами которые бы требовали нестандартное ядро линукса. Как максимум всякие виртуалбоксы модули таскают, но за это оно используется только казуалами для запуска винды раз в неделю. В продакшне все дружно любят kvm и прочие докеры. С ними мороки сильно меньше.
> Мы c 2006 года (https://openvz.org/History#2006)
> делаем продукт на базе модифицированного ядра от Red Hat, у нас всё хорошо,Ну и замечательно. Однако тренды по-моему совсем не в пользу openvz.
> клиенты довольны.
Я рад за них. Посмотрим через сколько они задолбаются таскать левые ядра, глядя на то как конкурент разворачивает докера 1 командой в дефолтной убунточке, а второй - запускает в этом докере свой сервис.
> А про успешные случаи монетизации LXC я пока не слышал.
Про LXC не скажу а докер вроде не бедствует, на KVM сейчас хосты не предлагает только совсем ленивый и глупый, etc.
>> А другие компании, которые делают свой продукт на базе Linux, вы тоже
>> предупредили о том, что их ждет?
> Я даже и не могу вспомнить других компаний занимающихся виртуализацией или контейнерами которые бы требовали нестандартное ядро линукса.RHEV
> RHEVЧто - RHEV? Редхат поставляет систему и кое-какой софт к ней. И ядро какое им там удобно. Поскольку у них работает половина разработчиков линя - они это еще и саппортить потом могут, даже если и пропатчили что-то относительно ванили. Не говоря о том что это не требует нестандартных телодвижений и у них есть саппорт всего этого.
А вот что делают клиенты || для меня загадка. У || ресурсов не как у редхата, в майнлайне с этой закорюкой тоже пошлют. Я не понимаю - клиенты || пишут в спортлото? Или делают рожу кирпичом перед своими клиентами, по цепочке?
> Мы c 2006 года (https://openvz.org/History#2006)
> делаем продукт на базе модифицированного ядра от Red Hat, у нас
> всё хорошо, клиенты довольны. А про успешные случаи монетизации LXC я
> пока не слышал.анонимы тролят, а не админят. я лично работал в продакшене и с openvz, и с LXC. LXC был для продакшена откровенно сырой, хотя на это и закрывали глаза. законченный продукт от отдельной команды в данном случае - это неоспоримое преимущество для бизнеса. а уж какое ядро использовать - это аргумент для троллинга не иначе.
> данном случае - это неоспоримое преимущество для бизнеса. а уж какое
> ядро использовать - это аргумент для троллинга не иначе.По-моему докер затроллил || жирнее всех, ухватив львиную долю рынка и став стандартом дефакто на рынке на котором имели все шансы быть ||. Десятилетие форменного $@%ланства с игнорированием проблем админов и того что сейчас называется DevOps имело свою цену. Теперь львиная доля продакшнов пользуется другими продуктами, от менее мерзких разработчиков.
>> данном случае - это неоспоримое преимущество для бизнеса. а уж какое
>> ядро использовать - это аргумент для троллинга не иначе.
> По-моему докер затроллил || жирнее всех, ухватив львиную долю рынка и став
> стандартом дефакто на рынке на котором имели все шансы быть ||.
> Десятилетие форменного $@%ланства с игнорированием проблем админов и того что сейчас
> называется DevOps имело свою цену. Теперь львиная доля продакшнов пользуется другими
> продуктами, от менее мерзких разработчиков.а по-моему докер - это просто мода. за него хватаются те, кто сам технологию оценить не может, а смотрит, что используют другие вокруг. я со всем этим имел дело и могу для себя решить, что доставляет мне меньше проблем.
и как вы оцениваете что для использования OpenVZ7 необходимо сразу форматировать под ext4, так как стандартная FS (XFS) не поддерживается для контейнеров.
> и как вы оцениваете что для использования OpenVZ7 необходимо сразу форматировать под
> ext4, так как стандартная FS (XFS) не поддерживается для контейнеров.а OpenVZ7 я никак не оцениваю. я же его не использовал. я думаю, контейнер на xfs сделать смогу. и да, мне нафиг не нужны все эти переделки утилит, если коммерческие фичи всеравно остаются платными. так для меня это просто пустая новость.
не сможете.
флага о виртуализации нету на этой FS.
ext4 нужен был для simfs, ныне не актуально.
> а по-моему докер - это просто мода. за него хватаются те, кто
> сам технологию оценить не может, а смотрит, что используют другие вокруг.А по-моему это голая прагматика. Вкатить докер - одна команда в большинстве дистров, включая попсовые убунты, любимые собственно Dev'ами. Dev'ы очень приветствуют такое же окружение при Ops'ах, чтобы не было дурных неожиданностей и вообще если что не так - они знали с какого бока к системе зайти.
Редхат - дерьмовенький и дорогой десктоп. И dev'ы им если где и пользуются, то очень местами и в энтерпрайзах, которые как раз и окучал RH. Поконкурироукть с RH в их нише мысль довольно забавная. А у || для этого есть разработчики? А то виденые хостеры все баги ядра коих разумеется есть - тихо сливали и воркэраундили как умели, например запретом сбоящих модулей, что очень радовало юзерей. Стоит ли говорить что у kvm этой проблемы нет и там если юзер прострелит себе пятку на своей машине, только ему же и будет хуже.
> я со всем этим имел дело и могу для себя решить,
> что доставляет мне меньше проблем.А ты не вся планета.
Это вы так ploop назвали ?а ссылочку вы классную показали - свалив в одну кучу in kernel виртуализацию и гипервизор. Где вас учили так передергивать ? за одно прикрутив в сравнение то что для других систем делается сторонними утилитами. Классно передергиваем :)
Если уж в табличке сравниваете решения - то сравнивайте - голые ядра. А бэкап и прочее можно и сторонними средствами накрутить.
> Остальным советую взглянуть на сравнение https://openvz.org/ComparisonА где VMware vSphere? Или справедливо решили не смешить людей? :-)
>> Остальным советую взглянуть на сравнение https://openvz.org/Comparison
> А где VMware vSphere? Или справедливо решили не смешить людей? :-)Вы можете туда добавить VMware vSphere, если хорошо разбираетесь в этом продукте.
По ссылке обычная вики, открытая для редактированию любому.
> Вы можете туда добавить VMware vSphere, если хорошо разбираетесь в этом продукте.Я думаю, и вы в нем разбираетесь достаточно, чтобы вписать туда этот столбец. Другой вопрос, что вы таким образом сравните телегу и самосвал (в случае vSphere). И сравнивать будете на основе количества колес, наличия железных кольев в деревянных колесах (понятно, что у самосвала их нету, так что там напишем красненькое "No") и удобных оглоблей (которых у самосвала, конечно же, тоже нет).
> Мы делаем полноценный продукт для виртуализации вместе с системой хранения данных и отказоустойчивостью.Не включаясь в ваш [бессмысленный] спор с анонимом, задам вопрос, который волнует лично меня. Я успешно использую openvz на EL6. Мне все очень нравится, утилиты vzctl в том числе, я не спешу на EL7. Теперь выходит новый продукт, а новый в моем случае означает новые грабли. Привычные утилиты меняют, на EL я теперь это ставить не могу - нарушен воркфлоу. Меня волнуют а) что с поддержкой openvz на EL6? она сохранится? б) риски миграции, описана ли процедура, success stories т.д. в) преимущества лично для меня. в коммерческой версии VZ была реализована своего рода дедупликация памяти: отслеживали загруженные библиотеки, делали ссылки, чтобы не загружать повторно. есть ли это в новом открытом продукте? т.е. я говорю не о KVM KSM.
наконец-то вопрос по делу>> Мы делаем полноценный продукт для виртуализации вместе с системой хранения данных и отказоустойчивостью.
> Не включаясь в ваш [бессмысленный] спор с анонимом, задам вопрос, который волнует
> лично меня. Я успешно использую openvz на EL6. Мне все очень
> нравится, утилиты vzctl в том числе, я не спешу на EL7.
> Теперь выходит новый продукт, а новый в моем случае означает новые
> грабли. Привычные утилиты меняют, на EL я теперь это ставить не
> могу - нарушен воркфлоу. Меня волнуют
> а) что с поддержкой openvz?
> она сохранится?Да, пока поддержка OpenVZ на ядрах 2.6.32/2.6.18 остаётся. Конкретных сроков прекращения поддержки нет. Но мы конечно же рекомендуем всем переехать на OpenVZ 7.
> б) риски миграции, описана ли процедура, success stories т.д.
процедура описана https://docs.openvz.org/virtuozzo_7_upgrade_guide.webhelp/_m...
success stories - если только в рассылке https://lists.openvz.org/pipermail/users/
> в) преимущества лично для меня. в коммерческой версии VZ была реализована
> своего рода дедупликация памяти: отслеживали загруженные библиотеки,
> делали ссылки, чтобы не загружать повторно. есть ли это в новом открытом продукте? т.е.
> я говорю не о KVM KSM.думаю вы говорите про технологию pfcache, она осталась только в коммерческой версии
Спасибо за ответ. Да, действительно pfcache - это то, что меня волновало. Видимо, я не так понял текст новости "слияния кодовых баз открытой системы контейнерной виртуализации OpenVZ и коммерческого продукта Virtuozzo (Parallels Cloud Server)". Я ожидал, что коммерческие фишки станут доступны всем, но, видимо, слияние в первую очередь проведено для наведения порядка в разработке продукта. Тогда эта новость пока не для меня.А как сейчас с поддержкой systemd? Работаете над этим? Я видел проблемы, когда сервисы с новой инит системой в контейнере просто не запускались.
> А как сейчас с поддержкой systemd? Работаете над этим? Я видел проблемы,
> когда сервисы с новой инит системой в контейнере просто не запускались.Не готов сейчас это прокомментировать, лучше написать в рассылку users@openvz.org или если есть описание конкретной проблемы, то в багтрекер https://bugs.openvz.org/
зачем вам этот глюкодром по имени pfcache? который мало того что глючит так еще имеет сильные проблемы с маштабируемостью.
> Но мы конечно же рекомендуем всем переехать на OpenVZ 7.нет-нет, там у вас еще известных проблем целый список, в том числе что-то с LTS (!) версиями Ubuntu. смысла ломать то, что работает нет. мы уж как-нибудь без передряг пока.:)
> Конкретных сроков прекращения поддержки нет.https://openvz.org/Releases - те с EOL заявленным срок поддержки не связан?
> Да, пока поддержка OpenVZ на ядрах 2.6.32/2.6.18 остаётся.
Но только самих ядер?
Про vzctl уже писали в багтрекере, что никаких фич добавлять в него не будете. И что даже баги никакие чинить не будете. С ploop-ом для openvz 6, как понял, аналогично.
>> Конкретных сроков прекращения поддержки нет.
> https://openvz.org/Releases - те с EOL заявленным срок поддержки не связан?EOL и сроки прекращения поддержки в стадии обсуждения, именно поэтому мне нечего ответить на этот вопрос.
>> Да, пока поддержка OpenVZ на ядрах 2.6.32/2.6.18 остаётся.
> Но только самих ядер?
> Про vzctl уже писали в багтрекере, что никаких фич добавлять в него
> не будете. И что даже баги никакие чинить не будете. С
> ploop-ом для openvz 6, как понял, аналогично.С багтрекером такая штука.
Linux ядра для OpenVZ и Virtuozzo практически идентичные. Поэтому множество багов, найденных в OpenVZ, справедливы и для Virtuozzo (и конечно же наоборот). Так как vzctl для OpenVZ и Virtuozzo отличаются (см текст новости), то баги OpenVZ vzctl не всегда валидны для Virtuozzo. Если раньше у нас были ресурсы чинить баги vzctl (посл релиз vzctl Кир выложил в августе 2015 и ploop в апреле 2016 https://openvz.org/Download/utils), то сейчас таких ресурсов нет в свете активной работы над OpenVZ/Virtuozzo 7 и вряд ли эти ресурсы появятся. Тем более что OpenVZ 7 унаследовал другую версию vzctl, от которой планируется отказаться в пользу prlctl в следующих версиях. Ещё учитывая, что никто из сообщества не возьмется за починку багов vzctl я их закрыл как WONTFIX, чтобы хоть немного почистить публичный багтрекер. Вообще это нормальная практика закрывать баги в багтрекере, для которых нет шансов быть исправленными.ИМХО лучше так, чем наблюдать багтрекер OpenVZ, забитый старыми неактуальными багами.
А когда ожидается назначение сроков жизни/поддержки для OpenVZ 7? Известны ли какие-то примерные сроки на данный момент?Планируется ли более подробно их описывать по этапам/компонентам?
Как тут, например, - https://access.redhat.com/support/policy/updates/errata/#Lif...
> ИМХО лучше так, чем наблюдать багтрекер OpenVZ, забитый старыми неактуальными багами.Имхо закрывать актуальные баги как Resolved Won't Fix не очень корректно. Так-как их не отделить от некорректных и действительно исправленных багов, что понижает вероятность, что их кто-нибудь все таки исправит. И соотв. сразу появляется такой вопрос. Пусть на их исправление у команды нет ресурсов, но планируется ли принимать пользовательские патчи и выпускать новые релизы на их основе, если их будет достаточное количество?
А так же есть ли смысл сейчас обращаться в платную поддержку с багами vzctl/ploop от openvz 6?
> А когда ожидается назначение сроков жизни/поддержки для OpenVZ 7? Известны ли какие-то
> примерные сроки на данный момент?
> Планируется ли более подробно их описывать по этапам/компонентам?
> Как тут, например, - https://access.redhat.com/support/policy/updates/errata/#Lif...
>> ИМХО лучше так, чем наблюдать багтрекер OpenVZ, забитый старыми неактуальными багами.
> Имхо закрывать актуальные баги как Resolved Won't Fix не очень корректно. Так-как
> их не отделить от некорректных и действительно исправленных багов, что понижает
> вероятность, что их кто-нибудь все таки исправит.Никто не мешает сделать фильтр по таким багам. Проблема в другом - никто не будет разбираться с этими багами, даже репортер который этот баг нашел. Из 100 закрытых багов отреагировали только в 3-х. Если у вас есть фикс, то переоткрывайте баг и заводите пулл-реквест.
> И соотв. сразу появляется
> такой вопрос. Пусть на их исправление у команды нет ресурсов, но
> планируется ли принимать пользовательские патчи и выпускать новые релизы на их
> основе, если их будет достаточное количество?Планируется https://openvz.org/How_to_submit_patches
> Из 100 закрытых багов отреагировали только в 3-х.Не факт, что это показатель. В своих так закрытых я "не реагировал", например.
Так-как с одной стороны было ясно, что какой-либо ответ в баг ничего не изменит.
Соотв. часть даже не заводилась уже в жире, так-как было ясно, что никто их трогать не будет и в лучшем случае их только закроют.> Планируется
Ок, а то после 29 дней тишины в пул реквесте на 50 строчек решил, что и на ревью и принятие патчей уже ресурсов нет.
Но про VZ7 и планы на счет сроков поддержки/более подробного из расписывания для компонент и тп чем openvz 6 хотелось бы что-то услышать.
Может быть не тут, а в sdcast хотя бы, если сейчас нет какой-либо информации.
> Ок, а то после 29 дней тишины в пул реквесте на 50
> строчек решил, что и на ревью и принятие патчей уже ресурсов
> нет.Я не нашел открытого PR в https://src.openvz.org/projects/OVZ. Пришлите пожалуйста ссылку на PR мне на почту sergeyb собака openvz.org
> Но про VZ7 и планы на счет сроков поддержки/более подробного из расписывания
> для компонент и тп чем openvz 6 хотелось бы что-то услышать.
> Может быть не тут, а в sdcast хотя бы, если сейчас нет
> какой-либо информации.Я уже отвечал и повторю еще раз: конкретных планов по прекращению поддержки предыдущей версии OpenVZ пока нет. Если для вас важно получить эту информацию то рекомендую подписаться на рассылку, там небольшой трафик.
>> Из 100 закрытых багов отреагировали только в 3-х.
> Не факт, что это показатель. В своих так закрытых я "не реагировал",
> например.
> Так-как с одной стороны было ясно, что какой-либо ответ в баг ничего
> не изменит.Вот поэтому и сложно строить какой-то диалог с пользователями OpenVZ.
> Соотв. часть даже не заводилась уже в жире, так-как было ясно, что
> никто их трогать не будет и в лучшем случае их только закроют.Завести баг мало. Люди обычно считают, что они отрепортили (чаще всего кое-как) проблему и дело сделано. Но к сожалению, это не так. Обычно данных о проблеме не хватает и у разработчика возникают дополнительные вопросы по воспроизведению, по окружению в котором этот баг случился и т.д. Если была паника в ядре, то например может потребоваться вывод от SysRq комбинаций. Если репортер не готов предоставить эту информацию и реагировать на вопросы в комментариях от разработчика, то баг можно считать бесполезным.
Из общения с вашими разработчиками - складывается впечатление что им все должны.
А слова о sysrq после паники это вообще LOL.
вы своих разработчиков crashdump не учили анализировать ?
> Из общения с вашими разработчиками - складывается впечатление что им все должны.Из своего опыта - работа над багом это всегда диалог репортера и разработчика.
> А слова о sysrq после паники это вообще LOL.
> вы своих разработчиков crashdump не учили анализировать ?Постоянное тыканье носом от каких-то троллящих анонимусов в комментариях - вот это LOL.
>> Из общения с вашими разработчиками - складывается впечатление что им все должны.
> Из своего опыта - работа над багом это всегда диалог репортера и
> разработчика.Только разработчики из parallels любят слушать себя. А других не очень.
>> А слова о sysrq после паники это вообще LOL.
>> вы своих разработчиков crashdump не учили анализировать ?
> Постоянное тыканье носом от каких-то троллящих анонимусов в комментариях - вот это
> LOL.Что поделать. Учитесь так жить. Некоторые анонимы имеют очень отрицательный опыт работы с вашими разработчиками. У того же Емельянова ЧСВ зашкаливает настолько что пока его не припереть к стенке детальным разбором бага - только тогда он сознается что есть проблема, но он не знает как ее решить.
До тех пор отрицает напрочь существование проблемы, придираясь к объяснениям.
Я понимаю вашу обиду когда разработчик не прочитал ваши мысли и потребовал деталей, но если вы хотите чтобы ваша проблема была исправлена, то вам прийдется научиться правильно составлять описание проблемы.Полезные ссылки:
https://openvz.org/Reporting_OpenVZ_problem
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
LOL :-) дядя пиши еще. Поверь - павлику тогда были представлены очень много доказательств бага в OpenVZ 6, и не один раз. но настолько упорного человека с повышеным ЧСВ еще поискать надо.Причем замечу - это мнение не только меня, а всех кто участвовал в тех разборках.
Очень любимая тема у него - съезжать с вопроса, прикатываясь что не сформулировано как ему хочется.
Или просто переставать отвечать в середине обсуждения.Я понимаю ваше желание защищать честь фирмы, но иногда не стоит этого делать дабы не выглядеть смешным.
вот пример из некого обсуждения
----
> теперь видите проблему?Уже давно. Всё жду, пока вы её нормально сформулируете. (c) xemul.
----как вы легко можете увидеть - павел - прекрасно видел в чем проблема, но что-то в его характере не позволяет ему спустится с небес к пользователю. Он ждет пока пользователь поднимется к нему.
Простите но такое поведение не говорит не о чем другом как о раздутом ЧСВ, не желании понимать пользователя, и помогать ему. Он просто ждет.. пока же все случится.
я понимаю вашу обиду за контору, но иногда не стоит ее защищать, а стоит признать свои ошибки.
доводилось общаться с павлом. и не раз. впечатления остались самые хорошие.
> Некоторые анонимы имеют очень отрицательный опыт работы с вашими разработчиками.Феерия...
> У того же Емельянова ЧСВ зашкаливает
Нет. Знаю его в нормальной жизни -- скромный грамотный толковый человек.
Судя по тому, что здесь пишете -- зашкаливает именно у безымянного "дарования".
PS: никак с параллельсами не связан.
> Феерия...Феерия - это ||.
> Нет. Знаю его в нормальной жизни -- скромный грамотный толковый человек.
Не мешает разработчикам || быть чудаками на букву м в рассылках, форумах и багтрекерах, что важнее. Взаимодействие по продукту ведеся там. И там каждый второй - Ульрих Дреппер.
> Судя по тому, что здесь пишете -- зашкаливает именно у безымянного "дарования".Тут зашкаливает у человек пяти наверное. У || неудобные продукты, наглые разработчики и неадекватные менеджеры. Использовать их продукты можно только будучи мазохистом.
>> Феерия...
> Феерия - это ||.Покажите свой код и своего работодателя, мистер никто.
>> Нет. Знаю его в нормальной жизни -- скромный грамотный толковый человек.
> Не мешаетВозможно, у Вас просто "да тут все по встречной". На этом и откланиваюсь.
мистер шигорин - главное что ваши хаки в свое время видели :) качеством этот код не отличался.
А качество кода parallels можно легко увидеть глянув в GIT.сначала мы закомитим что даже не компилируется - а потом попытаемся это пофиксить.
Как вы думаете какого качества код будет в результате ?
> мистер шигорин - главное что ваши хаки в свое время видели :)
> качеством этот код не отличался.Ещё раз: мой код под моим именем видеть _можно_.
Вы своё имя боитесь даже назвать, не говоря уж вытащить на белый свет _свои_ хаки.
Вот и вся цена Вашим словам.
а зачем :) мои хаки меня устраивают и очень большое количество клиентов тоже.
А вот ваш код годится только на помойку.
> а зачем :) мои хаки меня устраивают и очень большое количество клиентов тоже.Научился заправлять картриджи по-быстрому?
> А вот ваш код годится только на помойку.
Ваша обида понятна, но неприемлема.
> Научился заправлять картриджи по-быстрому?ДА!
А ты брат аноним такого не достиг ?
> Покажите свой код и своего работодателя, мистер никто.Фееричное спервадобейся. А работодатель я себе сам.
> Возможно, у Вас просто "да тут все по встречной".
По-моему это не у меня, я клиентам не хамлю и не заворачиваю их с багрепортами и патчами, да и черти-кем патченые ядра не всучиваю.
>> Покажите свой код и своего работодателя
> Фееричное спервадобейся. А работодатель я себе сам.
>> мистер никто
> По-моему это не у меня, я клиентам не хамлюПредпочитаете хамить разработчикам, как видим. Интересно, являясь ли при этом клиентом?
> Предпочитаете хамить разработчикам, как видим. Интересно, являясь ли при этом клиентом?В данный момент я уже нигде не использую их продукты жизнедеятельности. Раньше использовал местами, но - задолбался. Сейчас несколько значительно менее геморройных в применениях решений есть совершенно бесплатно. Может быть есть какие-то узкие ниши где OpenVZ еще имеет смысл, но кроме технически отсталых жадных хостеров которые благодаря проблемности технологии для клиентов все ближе к издыханию - ничего в голову не приходит уже. Хостеров с OVZ я тоже более не использую. Невозможность контроля над ядром - жирный факап в хостинге. Даже фаер не настроить, да еще головняк с сокетами и прочим. А для своих сервисов на своем железе - OVZ отчаянно неудобен и враждебен.
>> Предпочитаете хамить разработчикам, как видим. Интересно, являясь ли при этом клиентом?
> В данный момент я уже нигде не использую их продукты жизнедеятельности.
> Раньше использовал местами, но - задолбался.Взяв или купив?
> А для своих сервисов на своем железе - OVZ отчаянно неудобен и враждебен.
У меня за 10+ лет сложилось ровно противоположное мнение, ну да ладно.
>> А слова о sysrq после паники это вообще LOL.
>> вы своих разработчиков crashdump не учили анализировать ?
> Постоянное тыканье носом от каких-то троллящих анонимусов в комментариях - вот это
> LOL.Ах да, для чистоты стоит сказать о адекватных девелопера в Parallels - это максим патласов и давыдов (сори забыл имя), они пытаются разобраться в проблеме и чем-то помочь, а не гнуть пальцы как это любил делать xemul.
> Ах да, для чистоты стоит сказать о адекватных девелопера в Parallels -
> это максим патласов и давыдов (сори забыл имя),Владимир. Сообщество должно помнить своих героев.
> они пытаются разобраться в проблеме и чем-то помочь, а не гнуть пальцы как это
> любил делать xemul.
>> Ах да, для чистоты стоит сказать о адекватных девелопера в Parallels -
>> это максим патласов и давыдов (сори забыл имя),
> Владимир. Сообщество должно помнить своих героев.И антигероев тоже.
> Ещё учитывая, что никто из сообщества не возьмется за починку багов vzctl я их закрыл как WONTFIX, чтобы хоть немного почистить публичный багтрекер. Вообще это нормальная практика закрывать баги в багтрекере, для которых нет шансов быть исправленными.Вспоминается история - когда человека который предлагал фиксы для vzctl и улучшения послали далеко когда он отказался подписать документы о передаче прав на код в фирму Parallels.
С тех пор патчик на учет трафика и мелкие фиксы - гулял по форуму.
А вы теперь плачетесь что никто не фиксит баги ?
да да, скажите спасибо за то что задали удобный вопрос.Как-то вы не стремитесь ответить не неудобные вопросы.
> да да, скажите спасибо за то что задали удобный вопрос.
> Как-то вы не стремитесь ответить не неудобные вопросы.Если вам нечего сказать относительно нового релиза OpenVZ, то предлагаю вам продолжить троллинг в следующей новости. Там systemd новый вышел.
Тратить время на троллящих анонимусов я не готов.
Да да, есть. А правда что XFS (базовая FS от RHEL7) теперь не поддерживается? и как следствие миграция CentOS7/RedHat7 - в OpenVZ7 не возможна?
XFS никогда не поддерживался, ни как файловая система, в которой можно размещать ploop-ы, ни как файловая система внутри ploop-ов.
> XFS никогда не поддерживался, ни как файловая система, в которой можно размещать
> ploop-ы, ни как файловая система внутри ploop-ов.ploop не интересен. Интересен факт что имеем поставленый CentOS, RedHat и прочее.
Вкатываем ядро от OpenVZ и отгребаем стопки багов с комментарием "данная FS не поддерживается, отформатируйте свой диск в ext4".
> Если вам нечего сказать относительно нового релиза OpenVZ, то предлагаю вам продолжить
> троллинг в следующей новости. Там systemd новый вышел.Что, с systemd у параллелсов тоже что-то не срослось?
> Достаточно посмотреть на стиль разработки в git, что бы понять - что в датском
> королевстве что-то не ладно.И это нам будет рассказывать апологет оракла, верно?
PS: на следующий день наш, видимо, аульский друг продолжал тихо отмалчиваться на сей счёт...
>> Достаточно посмотреть на стиль разработки в git, что бы понять - что в датском
>> королевстве что-то не ладно.
> И это нам будет рассказывать апологет оракла, верно?Вы считаете это нормальным комит в публичный репозиторий кода который даже не компилируется ? Или нормальный стиль разработки когда ситуация "откатили патч из-за регрессий" это не аварийная ситуация - а обычное явление? Когда продукт не проходит даже минимального внутреннего тестирования а просто выкатывается клиентам.
Напомню другую ситуацию - достаточно долгое время OpenVZ7 ядро тупо паниковало при попытке установить на систему где есть хоть один xfs раздел. А ведь xfs это базовая FS после инсталляции RHEL / CentOS/и прочие клоны шапки.Еще раз спрошу - вы считаете такой стиль разработки не провоцирует баги в продукте?
>>> Достаточно посмотреть на стиль разработки в git, что бы понять - что в датском
>>> королевстве что-то не ладно.
>> И это нам будет рассказывать апологет оракла, верно?
> Вы считаете это нормальным комит в публичный репозиторий кода который даже не
> компилируется ?Вопрос на вопрос считать утвердительным ответом? Вообще же без CI на проектах заметного размера такое бывает, увы и ах.
> Или нормальный стиль разработки когда ситуация "откатили патч из-за
> регрессий" это не аварийная ситуация - а обычное явление? Когда продукт
> не проходит даже минимального внутреннего тестирования а просто выкатывается клиентам.То есть речь про продукт клиентам, а не тем, кто берёт из гита на свой страх и риск?
> Напомню другую ситуацию - достаточно долгое время OpenVZ7 ядро тупо паниковало при
> попытке установить на систему где есть хоть один xfs раздел.Странно, достаточно долго использовал на хостах как раз и с XFS (как вот ftp.linux.kiev.ua) -- было бы интересно узнать примерно годы или версии.
вот комит из их репы.
К счастью когда наступили на этот баг - оказалось его пофиксили за нас.commit 184af5da0ad2ac53df1692a7061b5845f4d0d944
Author: Vladimir Davydov <vdavydov@virtuozzo.com>
Date: Wed Oct 21 18:10:35 2015 +0400ve/xfs: add missing ub_io_account_dirty in set_page_dirty
..
Since we do not officially support XFS, it is not critical for us,
nevertheless let us fix it in case anybody tries to use it.
> а теперь есть богомерзкий докер и прочие lxc для приложений и нормальная
> полная виртуализация kvm/xen + всякие вмтвари и прочие сферические виртуалбоксыОни по крайней мере не требуют внебрачные ядра от посторонних лиц. Одно это требование гарантирует множество проблем администрирования и средний палец от админов и прочих девопсов.
> прочие сферические виртуалбоксыVirtualBox совсем другого класса продукт. Да и как моя практика показала, производительность при хоть сколько-нибудь значительной нагрузке (более 2-3 работающих виртуалок) у него никудышняя.
> версия соответствует ядру 3.10+Нде.
>> версия соответствует ядру 3.10+
> Нде.базируется на шапке. Но в целом этичный фейл - шапка уже скоро снимет 7.0 с базовой поддержки - а версия OpenVZ только только стала стабильной.
Все нормально - rhel7 сама только стала стабильной.
>код всех компонентов OpenVZ открыт под лицензией GPL
>нет никаких помех для портированияпо-моему, эти два высказывания противоречат друг другу
>>код всех компонентов OpenVZ открыт под лицензией GPL
>>нет никаких помех для портирования
> по-моему, эти два высказывания противоречат друг другуКак именно они противоречат?
Поддержка sVirt хотя бы в планах имеется?
> Поддержка sVirt хотя бы в планах имеется?Если я правильно понял, то тут имеется ввиду интеграция с SELinux.
С SELinux ситуация такая: сейчас у нас в ядре Virtuozzo/OpenVZ 7 опции SELinux выключены, но это кажется только по историческим причинам, потому что теперь контейнеры используют user_ns, в наших собственных капабилитях нет необходимости, поэтому вполне возможно, что можно попробовать включить опции, и на хосте должно заработать. В контейнерах не будет работать пока - SELinux не виртуализован, "не понимает" разные namespaces.
sVirt - это не обязательно только SELinux, но и AppArmor https://libvirt.org/drvqemu.html#securitysvirtК сожалению, с завидной регулярностью публикуются уязвимости позволяющие получить доступ к хост-системе из виртуальной машины или контейнера. Подавляющее большинство этих уязвимостей просто не работают на системах с поддержкой sVirt.
Слишком долго пилили. Поезд с Proxmox уже уехал, и он на рельсах LXC.Получается, что вы вроде как пилите им конкурента? Полноценный продукт, свой дистр и т.д.
Одно время мне нравилась OpenVZ, но отдельное ядро и базирование на RHEL это как привязывание себя одной ногой к стулу
> Linux ядро базируется на последней версии ядра от Red Hat - RHEL 7есть ли хотя бы в планах сделать параллельную ветку для debian/ubuntu?
>> Linux ядро базируется на последней версии ядра от Red Hat - RHEL 7
> есть ли хотя бы в планах сделать параллельную ветку для debian/ubuntu?Этого в планах нет.
а почему?
> а почему?Потому что компания Virtuozzo занимается коммерческой разработкой ПО. Это значит, что затраты на написание ПО, тестирование ПО, планирование новый версий, поддержку предыдущих версий должно как минимум окупаться.
Занимаясь планированием новой версии Virtuozzo мы в первую очередь рассматриваем запросы на новую функциональность от наших крупных клиентов и функциональность, которая была отложена нами ранее из-за нехватки ресурсов в предыдущих релизах. Интересы пользователей OpenVZ тоже учитываются, но не всегда возможно эти интересы учесть. Более подробно о процессе разработке вы сможете узнать в следующем выпуске подкаста SDcast.
Весной прошлого года мы проводили опрос (http://www.opennet.me/opennews/art.shtml?num=42275), результаты которого мы опубликовали в блоге (http://openvz.livejournal.com/51718.html). В опросе был вопрос: "какая функциональность отсутствует в OpenVZ с вашей точки зрения?"
Топ ответов на этот вопрос:
- Modern kernel support (at least RHEL7 kernel)
- Good web interface (cluster management: adding nodes, quorum management, logs, etc )
- ZFS support
- Upstream kernel support and availability in Linux distributives
- Better integration with OpenStack (especially networking)
- Support of Debian 8.0 JessieТогда, когда разработка OpenVZ 7 была в самом разгаре я прокомментировал каждый запрос.
Сейчас, когда релиз состоялся, можно сказать что 3 запроса из 6 были удовлетворены.
Мы перешли на новое ядро RHEL7, мы сделали возможность использования других бэкендов хранения данных, отличных от ploop и simfs, с помощью fs/storage пулов в LibVirt и сделали поддержку OpenStack (https://openvz.org/Setup_OpenStack_with_Virtuozzo_7).Поддержка Debian это большая работа, особенно учитывая что мы всегда использовали только RPM-based дистрибутивы для Virtuozzo. У нас пока на это ресурсов нет. Если у вас есть желание сдвинуть это с мертвой точки, то можно попробовать запакетировать основные компоненты OpenVZ в deb пакеты (https://openvz.org/Packages).
спасибо за равернутый ответ
Я как-то давно запускал openvz6-ядро на ubuntu. Кажется, это был 10.04 lucid.Запустилось с минимальными плясками (что-то там upstart-у не понравилось, подопнул одной строчкой, деталей не помню). После чего тривиально запакетил всю эту радость.
Попробуйте, может, и сейчас все просто. Или вам ебилды^W deb-ы готовые подавай? :)
А зачем все это? Для своих сервисов проще докер поставить. На продажу лучше сразу на kvm смотреть, меньше проблем и себе и клиентам.
Во времена 10-й убунты надо было, докеры и libcontainer-ы еще не были даже зачаты, а полноценная виртуализация там была нужна, как собаке пятая нога: по сути, openvz использовался для того, что сейчас называют модным словом "микросервисы".Сейчас - не знаю, зачем. :) Вон спрашивают, надо зачем-то, наверное. Лично мне не надо.
Актуальность продукта проще всего проверить на hh.ru
Docker Найдено 348 вакансий
OpenVZ Найдено 36 вакансий
Это по всей базе без учёта городов
Думаю очевидна востребованность продукта ;-)
> Актуальность продукта проще всего проверить на hh.ruА вернее -- по дыркотрекерам. И тут вдруг картинка получается ровно обратная: в ovz чинили нетривиальные ядерные дыры (т.е. сидеть на ovz-шном ядре "просто так" было безопасней, чем на шляпном), а вот в дыркер сажали детские и притом опасные.
Впрочем, метрика популярности довольно популярна, это да. Особенно если головой не думать.
> А вернее -- по дыркотрекерам. И тут вдруг картинка получается ровно
> обратная: в ovz чинили нетривиальные ядерные дыры (т.е. сидеть на ovz-шном
> ядре "просто так" было безопасней, чем на шляпном), а вот в
> дыркер сажали детские и притом опасные.А давай ты мне расскажешь, через какое время после фикса "дырки" в ядре RHEL'а фиксится ядро OVZ - а я полулыбаюсь:)
Школоте-то ты можешь лапшу на уши поразвешивать, а про то, как в дистрибутиве дыри в дре OVZ фиксятся (вернее, фиксились) усилиями мейнтейнера - можешь в чейнджлогах посмотреть.
> А давай ты мне расскажешь, через какое время после фикса "дырки" в
> ядре RHEL'а фиксится ядро OVZ - а я полулыбаюсь:)А это ещё один аспект, который для производного априорный (хотя мне и впрямь стоило явно обратить на него внимание для честности, так что спасибо тебе, что сделал за меня).
>> А давай ты мне расскажешь, через какое время после фикса "дырки" в
>> ядре RHEL'а фиксится ядро OVZ - а я полулыбаюсь:)
> А это ещё один аспект, который для производного априорный (хотя мне и
> впрямь стоило явно обратить на него внимание для честности, так что
> спасибо тебе, что сделал за меня).А давай ты расскажешь как положительно вливает на качество продукта стиль разработки при котором в репозиторий комитится не компилируемый код и после этого начинают его фиксить?
>> А давай ты мне расскажешь, через какое время после фикса "дырки" в
>> ядре RHEL'а фиксится ядро OVZ - а я полулыбаюсь:)
> А это ещё один аспект, который для производного априорный (хотя мне и
> впрямь стоило явно обратить на него внимание для честности, так что
> спасибо тебе, что сделал за меня).вот хотя бы так
Pavel TikhomirovPavel Tikhomirov
deacc4de82d ve/fs/overlay: allow overlayfs to be used inside a Container
бах..
а потом через 2 месяца и кучу фиксов выясняется что это же все же tech preview и надо бы запретить..Maxim committed af1bf9e1a0613 июл 2016
fs: make overlayfs disabled in CT by defaultбабах..
А сразу подумать нельзя было? если уж включать фичу - то когда она стабильна. не так ли ?
| вот хотя бы так
| Pavel TikhomirovPavel Tikhomirov
| deacc4de82d ve/fs/overlay: allow overlayfs to be used inside a Container
| бах..
| а потом через 2 месяца и кучу фиксов выясняется что это же все же tech preview и надо бы | запретить..А что, прочитать мессадж коммита сил не хватило?
> ve/fs/overlay: allow overlayfs to be used inside a Container
>
> This is temporary decision to make Docker in CT work with overlayfs
> storage driver, it can be unsafe to give access to fs-overlay module
> from container.
> ...
> overlayfs stibility in current RHEL7 kernel has not been checked
> yet, so it can be used for testing purposes only for now.Очевидно, что эту фитчу включили, чтобы потестировать. Потом выключили, потому что пока эта фс не готова к production use.
> А сразу подумать нельзя было? если уж включать фичу - то когда она стабильна. не так ли ?
Нет, не так ли. Вы, к сожалению, имеетка крайне скудное представление о том, как тестируются большие программные комплексы.
>[оверквотинг удален]
> > ve/fs/overlay: allow overlayfs to be used inside a Container
> >
> > This is temporary decision to make Docker in CT work with overlayfs
> > storage driver, it can be unsafe to give access to fs-overlay module
> > from container.
> > ...
> > overlayfs stibility in current RHEL7 kernel has not been checked
> > yet, so it can be used for testing purposes only for now.
> Очевидно, что эту фитчу включили, чтобы потестировать. Потом выключили, потому что пока
> эта фс не готова к production use.Адекватный разработчик не включает по умолчанию фичу, которая не стабильна. В частном репозитории вы можете включать себе хоть что угодно "на протестировать". Но комит оказался в публичном репозитории.
Кто-то из пользователей может скачать и запустить ее не желая того.
В виду этого Максим поступил сильно адекватнее автора первого комита, запретил по умолчанию и позволил кому надо ее включать.
Но кому я рассказываю :) супер спецам - которые и сами должны знать такую мелочь.. ну забыли.. ну наплевали на пользователей. С кем не бывает ?Еще раз напоминаю - есть разница между комитом не стабильного кода в частный репозиторий (где и тестируют то), и комитом в публичный - из которого люди могу себе поставить. Судя по ответам - отвественности за качество кода в публичном репозитории - вы не хотите нести.
>> А сразу подумать нельзя было? если уж включать фичу - то когда она стабильна. не так ли ?
> Нет, не так ли. Вы, к сожалению, имеетка крайне скудное представление о
> том, как тестируются большие программные комплексы.Ну да ну да :) Я мочу. Ведь для вас клиенты OpenVZ это подопытные кролики, ну упало у них - и хрен сними, это же не коммерческие клиенты Виртуозы :) за падение в виртуозе можно и по ушам получить, и имидж себе испортить.
> Адекватный разработчик не включает по умолчанию фичу, которая не стабильна. В частном
> репозитории вы можете включать себе хоть что угодно "на протестировать".
> Но комит оказался в публичном репозитории. Кто-то из пользователей может
> скачать и запустить ее не желая того.Коммит в публичном репо просто потому, что эти ребята открыто ведут разработку. Обычному пользователю будет ой как непросто "скачать и запустить" этот код из репо. Так что не надо передергивать. Перед релизом они как-раз отключили эту фитчу.
да вы что?! открыли мне глаза на открытую разработку. Спасибо милый человек!вы видели как идет разработка в ядре?
разработчик делает свою работу в собственном репозитории - и когда работа закончена следует pull request и наработки вливаются в публичный репозиторий. В тот момент когда фича объявляется стабильной.
Вы считаете что этот метод неправильным? Линукс ошибается выбрав такой стиль ? сейчас же откройте ему глаза о том что он не прав!Приметильно к этому случаю - посмотрите на комит максима. Включение экспериментальной фичи производится выключателем, с явного требования пользователя. Таким образом минимизируются проблемы для тех кто не хочет тестировать сырой код. Что мешало сделать так с самого начала?
> разработчик делает свою работу в собственном репозитории - и когда работа закончена следует pull request и наработки вливаются в публичный репозиторий.нет, разработчики обычно патчи шлют в рассылку. пулл реквесты засылают мэйнтейнеры.
> В тот момент когда фича объявляется стабильной.
опять мимо. фитча стабильной становится после пары релизов, в лучшем случае. в худшем - уходят годы на стабилизацию, особенно если сложная подсистема.
> Вы считаете что этот метод неправильным? Линукс ошибается выбрав такой стиль ? сейчас же откройте ему глаза о том что он не прав!
Похоже вы не понимаете как работает lkml. Врочем, ничего удивительного, вы привыкли делать ошибки.
> опять мимо. фитча стабильной становится после пары релизов, в лучшем случае. в худшем - уходят годы на стабилизацию, особенно если сложная подсистема.Да? напомните хоть один случай когда lkml принял патч который не компилируется? Зато в случае OpenVZ таких патчей был вагон.
commit ca2fd42ebda0669b0368db7c0929607cd79c5dac
Author: Dmitry Safonov <dsafonov@virtuozzo.com>
Date: Sat Jan 23 17:17:00 2016 +0400ve/binfmt_misc: fix compilation outside CONFIG_BINFMT_MISC
Fix for the next compile error:
kernel/ve/ve.c: In function ‘ve_destroy’:
kernel/ve/ve.c:709:10: error: ‘struct ve_struct’ has no member named ‘binfmt_misc’
kfree(ve->binfmt_misc);
commit 48645523b66c6e45463a2d9e721babf7d8c52520
Author: Kir Kolyshkin <kir@openvz.org>
Date: Thu May 7 20:28:39 2015 +0400bc/ioprio: ub_set_ioprio() declaration if !CONFIG_BEANCOUNTERS
This was found while tring to compile the kernel with a stock
config (i.e. no CONFIG_BEANCOUNTERS, CONFIG_VE etc.) and
boot it on IBM Power8.
=============================================================
Fix this:
CC fs/ioprio.o
fs/ioprio.c: In function ‘SYSC_ioprio_set’:
fs/ioprio.c:162:4: error: implicit declaration of function
‘ub_set_ioprio’ [-Werror=implicit-function-declaration]
ret = ub_set_ioprio(who, data);
commit 44d396dc06f0f41130ce69bdbb3e12925f31356c
Author: Vladimir Davydov <vdavydov@parallels.com>
Date: Wed Oct 9 12:10:48 2013 +0400net: remove include/net/netlink_sock.h
After the patchset applied the kernel compiles (if CONFIG_FUSE_FS is off),
boots and allows starting containers. Fixing broken fuse bits will be done
a bit later.
> Похоже вы не понимаете как работает lkml. Врочем, ничего удивительного, вы привыкли делать ошибки.Зато вы отлично понимаете :) я рад за вас - но искренне соболезную вашим пользователям. Которые доверяются вам.
> Да? напомните хоть один случай когда lkml принял патч который не компилируется? Зато в случае OpenVZ таких патчей был вагон.Снова ошибаетесь, как обычно.
http://www.spinics.net/lists/linux-rt-users/msg14393.html
> Зато вы отлично понимаете :) я рад за вас - но искренне соболезную вашим пользователям. Которые доверяются вам.
Спасибо, что рады за меня, но не стоит, я работаю в другой конторе (гораздо более крупной), поэтому знаю, насколько сложно выпускать большие программы.
Еще дам информацию для размышления -- знаете ли вы, что у того же редхата ядра не компиляются с кастомными конфигами? Тупо валятся с ошибками. Такие дела...
>> А вернее -- по дыркотрекерам. И тут вдруг картинка получается ровно
>> обратная: в ovz чинили нетривиальные ядерные дыры (т.е. сидеть на ovz-шном
>> ядре "просто так" было безопасней, чем на шляпном), а вот в
>> дыркер сажали детские и притом опасные.
> А давай ты мне расскажешь, через какое время после фикса "дырки" в
> ядре RHEL'а фиксится ядро OVZ - а я полулыбаюсь:)
> Школоте-то ты можешь лапшу на уши поразвешивать, а про то, как в
> дистрибутиве дыри в дре OVZ фиксятся (вернее, фиксились) усилиями мейнтейнера -
> можешь в чейнджлогах посмотреть.А давай ты расскажешь как положительно влияет на работу контейнеров попытка затормозить ext4 журнал ввиду того что один из контейнеров превысил свой IO limit, а контейнеры используют shared FS - дабы слегка памяти по экономить ?
https://src.openvz.org/projects/OVZ/repos/vzkernel/browse/fs...
код приводящий к
https://src.openvz.org/projects/OVZ/repos/vzkernel/browse/ke...aka wait.
неправда ли хороший образец кода - как делать не надо ?
> ядре "просто так" было безопасней, чем на шляпном), а вот в
> дыркер сажали детские и притом опасные.На форумах блэкхэтов хватает эксплойтов пробивающих OpenVZ. Поэтому жадные хостеры превращаются в рассадники. Были даже случаи когда из майнлайна бэкпортировали vulns в шапочное ядро, оттуда - в openvz. Потом в mainline vuln чинят, а эти горе-портере...