Bug 13146

Summary: Прошу добавть в setup-bri возможность запуска из командной строки
Product: Sisyphus Reporter: solo <solo>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: NEW --- QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P2 CC: evg, ldv, rider, sem, shaba, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   
URL: http://lists.altlinux.org/pipermail/devel/2007-September/063065.html
Bug Depends on:    
Bug Blocks: 13147    

Description solo 2007-10-17 15:23:00 MSD
Прошу добавть в setup-bri возможность запуска из командной строки.

Данная возможность реализована в etcnet-0.9.3-alt3.1 (см.
<http://git.altlinux.ru/people/solo/packages/?p=etcnet.git;a=commit;h=4c13196debd81e628d38f33012310fb7d7de54e4>),
отправленном в Daedalus.
Comment 1 Denis Ovsienko 2007-10-17 21:04:20 MSD
Здесь также только патч на спекфайл.
Comment 2 Denis Ovsienko 2007-10-17 21:07:13 MSD
Нашёл патч на setup-bri. Вы бы не могли описать задачу, которая решается таким
кровавым способом?
Comment 3 solo 2007-10-18 07:52:05 MSD
Задача автодобовления интерфейса поднятого сторонними средствами (не через
etcnet) в бридж.

У меня это используется для работы с veth* (см.
<http://lists.altlinux.org/pipermail/sysadmins/2007-October/011963.html>):

  Мне понравилось работать с veth через бриджи. Алгоритм примерно такой:

1. Создаём бриджи (с IFUP_PARENTS=no, чтобы мог подниматься при
отсутствии родителей), и все настройки делаем в них.

2. veth загоняем в нужные бриджи.

3. При поднятии VE -- реконфигурируем бриджи (дёргаем setup-bri)

В данном случаи, основная поблема в том, что для пднятия veth ovz использует
свои средства, со скриптами конфигурирования сети (etcnet, в даном случаи) никак
не связанные. Единственное что можно -- вызвать свои скрипты после поднятия.
Нужный функчионал (кроме возможности независимого запуска) в штатном setup-bri
уже содержится.
Comment 4 Denis Ovsienko 2007-10-19 01:28:17 MSD
Вы не поверите, но я вообще не использую виртуализацию. Может, объясните мне по
шагам, как наглядно увидеть решаемую проблему? Инсталляция S4.0 у меня есть.
Comment 5 solo 2007-10-19 12:40:32 MSD
Полная модель:

1. Поставить ovz ядро, vzctl и модули alterator`а для управления данным
хозяйством (можно и без них, но так проще).

2. Создать тесовую VE, с id`om <veid> (используя любой шаблон).

3. Добавить в данную VE veth интерфейс:

vzctl set <veid> --save --netif_add <ifname>

4. Стартануть VE, если это ещё не сделано.

  На данный момент в сестеме должен быть интерфейс вида veth<veid>.0

5. Создать бридж brd с IFUP_PARENTS=no и HOST='veth<veid>.0' и запустить его...

  Испытания:

1. В данный момент имеем:

а) поднятый интерфейс veth<veid>.0

б) поднятый бридж brd, содержащий в себе veth<veid>.0

2. Останавливаем VE:

vzctl stop <veid>

Посли остановки имеем:

а) фактическое отсутствие интерфейса veth<veid>.0

б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0

3. Запускаем VE:

vzctl start <veid>

Посли старта имеем:

а) поднятый интерфейс veth<veid>.0

б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0

3.б -- это то самое, пути решения чего я и предлогаю...
Comment 6 solo 2007-10-19 13:06:37 MSD
Как понимаю, причина данного поведения в следующем:

1. На уровне etcnet сами интерфейсы veth неописаны ни как: данная система
неможет ими управлять. Простых путей добавить туда эту возможность я невижу --
veth, это внутренняя кухня OVZ, и всё управлене жёско завязанно на vzctl.

2. OVZ, в свою очередь -- неимеет понятия о бриджах, тунелях и пр.. Но оно может
создавать/убивать veth интерфейсы... И vzctl можно обучить выполнять наперёд
заданный скрипт после создания veth интерфейса (можно ли передать имя созданного
veth как параметр данного скрита я непомню, но скорее всего можно).

  Сейчас (в #13147) я решаю данную проблему взаимодействия через скрипт
veth-update_bri (см.
<http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=blob;f=scripts/veth-update_bri.in;h=4d3b6c7eca8477ff334f7e4799c4b0f0df1b216f;hb=2ad9a256e21f01deb5802d0475143f1cd5f4091b>),
дёргающий setup-bri для активных бриджей. Но для этого мне нужно, чтобы
setup-bri допускал запуск из стороннего скрипта.

Если есть болие правельный путь -- готов подумать над его реализацией...
Comment 7 Denis Ovsienko 2007-10-19 16:24:08 MSD
Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного
контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать и
уехать он может в любой момент по велению высших сил. Мне кажется, что
предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим сторонам.
Почему бы не ограничиться тем, что хост-система (в данном случае посредством
etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой
самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и
цеплять их куда им положено? Можно такой обработчик поместить в /etc/net/scripts.
Comment 8 solo 2007-10-19 18:02:32 MSD
(In reply to comment #7)
> Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного
> контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать
> и уехать он может в любой момент по велению высших сил.

  Да.

> Мне кажется, что
> предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим
> сторонам.

  Прошу пояснить вашу мысль: мне не кажется, что предложенное изменение в
скрипте setup-bri способно повредить etcnet (скорее наоборот: это дополнительный
+, упрощающий интеграцию с другими системами).

> Почему бы не ограничиться тем, что хост-система (в данном случае посредством
> etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой
> самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и
> цеплять их куда им положено? Можно такой обработчик поместить в
> /etc/net/scripts.

  Выглядит несовсем логично: такой обработчик должен знать какой интерфейс в
какой мост поместить. И это знание _полностью_ бедет дублировать информацию
которую уже имеет etcnet (в конфигах мостов). При этом всплывут вопросы:

1. Как обрабатывать случаи противоречия данной инфы (и зачем допускать саму
возможность их возникновения)?

2. Как обрабатывать случаи различия состава интерфейсов в мостах в зависимости
от про etcnet`овского профиля?

  Для их решения, придётся слишком жёско привязывать обработчик к etcnet и
дублировать часть etcnet`овской функциональности. Не думаю, что это правельно...

  На мой взгляд, болие логичным выглядит возможность каким либо образом сказать
etcnet что-то типа: "Конфигурация сети изменилась. Действуй."

PS: Может стоит перенести обсуждение в sysadmins@?
Comment 9 Denis Ovsienko 2007-10-19 18:36:08 MSD
Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет.
Comment 10 solo 2007-10-19 18:46:05 MSD
(In reply to comment #9)
> Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
> интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет.

Как тогда обробатывать зависимость соства объединённых в мост veth от активного
профиля etcnet? (Могу привести примеры ситуаций, когда такое желательно.)
Comment 11 solo 2007-10-19 19:06:06 MSD
  Дополню:

  Профили -- одна из главнейших фич etcnet, и я весьма хочу, чтобы получившиеся
решение было с ними совместимо. (Хотя предложенное мной -- пока нет.)
Comment 12 Denis Ovsienko 2007-10-19 20:05:18 MSD
Хотелось бы увидеть примеры, да.
Comment 13 solo 2007-10-20 00:39:48 MSD
Простое преврощение ноута в небольшой сервер сети: несколько профилей
соответствуют нескольким сетям и нескольким наборам запускаемых VE.