1 (25.02.2014 11:10:31 отредактировано Cruiser78)

Вышел, вобщем, сабжевый релиз. Обещано, что помимо всего прочего, туда включена поддержка хранилища GlusterFS. Что обнадёжило. Решил попробовать.
Дано (для на попробовать):
1. Fedora 19 с развернутыми ранее тестовыми виртуалками.
2. Glusterfs стоит там из коробки.
3. Управляем виртуалками с помощью virt-manager 0.10.0

То есть - проблем не ждем.

Скачиваем исходный код virt-manager'а 1.0.0 с оффсайта, распаковываем и делаем rpm'ы способом, определенным в соответствующем сопровождающем файле. Далее - устанавливаем их. И опаньки....
Опаньки следующие:
- новый virt-manager рассчитан на применение gtk+ версии 3.10. При этом в F-19 установлена версия gtk+ версии 3.8. Смотрим на официальный сайт gtk+ и видим, что там последняя stable версия тоже 3.8. Что есть gtk+ версии 3.10???? Откуда оно должно в стабильной ветке взяться? И когда??? Забавный ход мысли у разработчиков virt-manager - тащить в продакшн не stable-релизы :-)
- ладно, смиряемся с тем, что часть функционала отвалилась напрочь, пытаемся сделать glusterfs-хранилище. Дополнительно к имеющимся. Индейское национальное жилище. Фигвам, то есть. Получаем сообщение, что virt-manager не может создать glusterfs-пул, так как не знает, что это такое...

Ну как так можно?

2

Ну GTK3 уже есть и 3.10 и даже 3.11. В продакшн их ни кто не тащит, кроме админов.
virt-manager 1.0.0 вряд ли будет собран для Ф19 вообще, а в Ф20 уже он есть.

3

Vascom пишет:

Ну GTK3 уже есть и 3.10 и даже 3.11. В продакшн их ни кто не тащит, кроме админов.
virt-manager 1.0.0 вряд ли будет собран для Ф19 вообще, а в Ф20 уже он есть.

А в СентОСи? Я же про чуть другое писал - есть последний stable релиз GTK+. Это, по официальным данным - 3.8. С какой радости надо искать себе приключений с релизами, которые находятся пока еще в разработке?

4

А в центос и не надо virt-manager 1.0.0 тащить - используй старый.

Или ты не знал, что варинтов всего три:
1. Всё стабильно, энтерпрайзно, для продакшена, безопасно. Но древнее, малофункциональное и медленное.
2. Всё новое, быстрое, функциональное. Возможны проблемы со стабильностью и безопасностью.
3. Помесь двух первых.

Так что выбирай: или быстро и круто, или медленно и тупо, либо сам смешивай их в нужных лично тебе пропорциях.

5 (25.02.2014 15:21:54 отредактировано Cruiser78)

Vascom пишет:

А в центос и не надо virt-manager 1.0.0 тащить - используй старый.

Дык для меня - самый цимес в Сентоси иметь виртуальные машинки, которые лежат в глустере... Ну и управлять ими с помощью простенького virt-manager'а, без всяких там оVirt'овских наворотов...

Попробовал более новый GTK+ на fedora-19 установить. Уперлось при ./configure в

 Консоль:
Requested 'glib-2.0 >= 2.37.5' but version of GLib is 2.36.4

А в 6-й Центоси - там вообще версия 2.26.1 живет...
Не понимаю, на какой дистрибутив оно при написании рассчитывалось. Ну нельзя же так...

6

Cruiser78 пишет:

какой дистрибутив

Fedora 20?

7 (25.02.2014 15:32:18 отредактировано Vascom)

Да, я же сказал, в Федоре 20 уже этот вирт-менеджер 1.0.0 в коджи собран.
Не все любят на древнем ПО сидеть.

8 (25.02.2014 15:41:21 отредактировано alexfinn)

ну да, в тестинге лежит уже 1.0.0

9

Vascom пишет:

Да, я же сказал, в Федоре 20 уже этот вирт-менеджер 1.0.0 в коджи собран.
Не все любят на древнем ПО сидеть.

И что? Переводить сервера виртуализации со стабильной и устойчивой (и поддерживаемой до 2020 года) CentOS'и 6-й на Fedora-20? И через год снова переводить на что-то? Мне одному кажется, что это безумие?

10

Если ты хочешь новый функционал, то либо жди когда его бэкпортируют, либо жди CentOS 7 с надеждой, что это там будет.
Понимаешь, разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО.

11

Vascom пишет:

разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО

на самом деле, это можно сказать по-другому:
с учетом зависимостей, гораздо больше шансов, что новые версии будут в RHEL 7... поскольку портировать GTK3 на 6 версию никто не будет, слишком много геммороя и никому это не нужно... а поскольку апстрим сейчас - GTK3, то и новые версии пишутся с учетом этого

12

Vascom пишет:

Если ты хочешь новый функционал, то либо жди когда его бэкпортируют, либо жди CentOS 7 с надеждой, что это там будет.
Понимаешь, разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО.

CentOS 6 (RHEL 6) - это древняя версия? А есть что поновее? Сам же пишешь, что RHEL-7 еще нет, его надо ждать. Так что, CentOS-6 - вполне современная и экплуатируемая версия. Как ни крути.

А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19 (или 18? Уж не помню точно). Следовательно и там будут проблемы с зависимостями, на которые я наступил... И что, тоже объявим RHEL-7 устаревшей версией?

Для кого тогда пишется весь этот инструментарий?

13

alexfinn пишет:

а поскольку апстрим сейчас - GTK3, то и новые версии пишутся с учетом этого

Я ни разу не против, что апстрим это GTK3. Но ограничением версии этого GTK3 разработчики сильно уж потенциальную аудиторию обрубили.

14

Cruiser78 пишет:

А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19

при выходе 7 хотя бы будет смысл портировать новые версии
на данный момент, в бете сейчас версия 0.10.0... 1.0.0 идет после нее

15

Cruiser78 пишет:

разработчики сильно уж потенциальную аудиторию обрубили

потенциальную аудиторию чего? RHEL и CentOS? так там используется та версия, которая поддерживает те штуки, которые есть в соответствующих версиях KVM и Qemu. Установка новой версии virt-manager не добавит толком возможностей, поскольку может измениться в чем-то формат конфигов, какие-то опции в них и т.д. Соответственно, RH не может портировать на предыдущие версии весь новый софт, поскольку это нужно конкретно так тестить и поддерживать продолжительное время...

16 (25.02.2014 17:03:59 отредактировано Cruiser78)

alexfinn пишет:

RHEL и CentOS? так там используется та версия, которая поддерживает те штуки, которые есть в соответствующих версиях KVM и Qemu. Установка новой версии virt-manager не добавит толком возможностей

Полнейшее заблуждение. Современный KVM/QEMU поддерживают работу виртуальных машин, образы которых размещенны в хранилище типа glusterfs. Версия Virt-Manager 0.10 не позволяет как-либо манипулировать таким хранилищем и машинами, в нем размещенными. Эта возможность заявлена (но у меня не заработала) только в версии Virt-Manager 1.0.0. Так что, добавляемая возможность - существенная. А учитывая то, что RH ставит именно на KVM+glusterfs (причем, начиная с версии 6.5) непонятно, почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH.

17

Спроси у RH. Например создай багрепорт с просьбой обновить вирт-менеджер.
Там тебе может и ответят, особенно если платная поддержка тобой куплена.

18

Cruiser78 пишет:

почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH

например потому, что GTK3 в принципе отсутствует в 6 версии, например... а выпускать virt-manager с поддержкой GTK2 нет смысла тем более...

19

Cruiser78 пишет:

А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19 (или 18? Уж не помню точно). Следовательно и там будут проблемы с зависимостями, на которые я наступил... И что, тоже объявим RHEL-7 устаревшей версией?

я наверное уже миллион раз объяснял как работает процесс, но поворюсь, чтоб пресечь панику
1. берется самая свежая стабильная федора
2. клонируется в отдельный репозиторий
3. начинается полноценный QA и доработка багов. плюс конечно же замена логотипов и имен
4. на момент конца цикла QA федора уже скорее всего ушла на один релиз вперед, так что помимо багфиксов в ветку уже начинают идти бекпорты.

на выходе получаем RHEL, после нескольких циклов проверок и исправлений, с ядром и пакетами в которых уже столько бекпортов, что он никак не может быть просто клоном оригинальной федоры.

Cruiser78 пишет:

Полнейшее заблуждение. Современный KVM/QEMU поддерживают работу виртуальных машин, образы которых размещенны в хранилище типа glusterfs. Версия Virt-Manager 0.10 не позволяет как-либо манипулировать таким хранилищем и машинами, в нем размещенными. Эта возможность заявлена (но у меня не заработала) только в версии Virt-Manager 1.0.0. Так что, добавляемая возможность - существенная.

существенная но не критичная - гластер это не часть стека виртуализации, а только опциональный компонент. virt-manager != gluster-manager

А учитывая то, что RH ставит именно на KVM+glusterfs (причем, начиная с версии 6.5) непонятно, почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH.

ставит что? gluster сам по себе продукт и без виртуализации, это называется RHES. RHEV/ovirt тоже может управлять гластером. RHOS тоже его поддерживает. так что на энтерпрайз уровне все схвачено, а добавки в virt-manager это то что называется "nice to have".