Bug 13146 - Прошу добавть в setup-bri возможность запуска из командной строки
: Прошу добавть в setup-bri возможность запуска из командной строки
Status: NEW
: Sisyphus
(All bugs in Sisyphus/etcnet)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
: http://lists.altlinux.org/pipermail/d...
:
:
: 13147
  Show dependency tree
 
Reported: 2007-10-17 15:22 by
Modified: 2013-01-24 12:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-10-17 15:23:00
Прошу добавть в 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 From 2007-10-17 21:04:20 -------
Здесь также только патч на спекфайл.
------- Comment #2 From 2007-10-17 21:07:13 -------
Нашёл патч на setup-bri. Вы бы не могли описать задачу, которая решается таким
кровавым способом?
------- Comment #3 From 2007-10-18 07:52:05 -------
Задача автодобовления интерфейса поднятого сторонними средствами (не через
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 From 2007-10-19 01:28:17 -------
Вы не поверите, но я вообще не использую виртуализацию. Может, объясните мне по
шагам, как наглядно увидеть решаемую проблему? Инсталляция S4.0 у меня есть.
------- Comment #5 From 2007-10-19 12:40:32 -------
Полная модель:

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 From 2007-10-19 13:06:37 -------
Как понимаю, причина данного поведения в следующем:

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 From 2007-10-19 16:24:08 -------
Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного
контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать и
уехать он может в любой момент по велению высших сил. Мне кажется, что
предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим
сторонам.
Почему бы не ограничиться тем, что хост-система (в данном случае посредством
etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой
самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и
цеплять их куда им положено? Можно такой обработчик поместить в
/etc/net/scripts.
------- Comment #8 From 2007-10-19 18:02:32 -------
(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 From 2007-10-19 18:36:08 -------
Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не
будет.
------- Comment #10 From 2007-10-19 18:46:05 -------
(In reply to comment #9)
> Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
> интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет.

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

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