Т.е. туда будут больше заходить, чтобы что-то прочитать, или чтобы написать?

Написать

Будут приходить с проблемой

Мне кажется, нужно сделать, чтобы этим было удобно пользоваться тем, на кого мы в первую очередь ориентируемся.

IRC и почтовые рассылки (как здесь предложили) мне поэтому не очень нравятся -- они ориентированы на тех, кто 90%+ времени в консоли сидит, а таких все меньше.

Хотя под написать-ответить должны подходить хорошо.

А чем вам идея с каналом в телеграмм не нравится? для оперативной помощи?

если параллельно ведется >2 разговоров, уже напряжно

Канал плох тем, что в нем нет поиска

Он не индексируется поисковиками

Оперативная помощь - да

Как инструмент помощи сразу многим - нет

Опять же, в зависимости от формата: вопрос-обсуждение-ответ - форум, новости/гайды-обсуждение - коллективный блог, общение/оперативная помощь - чат/канал

Да

Однако перед тем как обсуждать инструменты хотелось бы видеть бриф, который был обещан. С идеями как развивать комьюнити, насколько я понял.

Бриф будет.

в телеграме есть поиск по тегам (#openstack) причем, разом по всем чатам/каналам, которые есть у тебя

наверняка есть боты, которые публикуют логи на сайте

Я бы подождал брифа всё таки, а уже потом обсуждать его техническую реализацию.

Как ни крути нужна педивикия и форум OS, отдельно можно сделать страничку, куда будет бот дампить переписку из телеграмма

Главное бизнес не убить) А то в это комьюнити все полезут)

Регистрацию через подтверждение модераторами/администраторами сделать

А контент на общее обозрение фильтровать

Ну и донат ввести за оперативность )

Хз луги бесполезны имхо

По крайней мере в московских масштабах

ЛУГ-и никто сейчас не предлагает. Хотя опыт проведения метапов в Казани показывает, что формат нужный и востребованный

Нам бы для начала общую платформу создать

Да и интернет с того времени продвинулся далеко вперед

Уже проще с коммуникациями

ЛУГ-и никто сейчас не предлагает. Хотя опыт проведения метапов в Казани показывает, что формат нужный и востребованный

Я потому и задавал вчера вопросы о формате, что все за последние лет 5 поменялось немало -- больше, чем за предыдущие 5 лет.

По самому OS ведутся разговоры ?

Вобщем, вопрос такой.

Разбираюсь с архитектурой cinder и не могу понять документацию, почему-то она описывает одно, но скрывает другое. Настраиваю nfs драйвер для cinder, вот конфигурация: [DEFAULT] enabled_backends=NetAppNfsBackend [NetAppNfsBackend] volume_backend_name=NetAppNfsBackend volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver netapp_server_hostname=netapp netapp_server_port=80 netapp_storage_protocol=nfs netapp_storage_family=ontap_7mode netapp_login=cinder netapp_password=password #netapp_vserver=svm_name nfs_shares_config=path_to_nfs_exports_file max_oversubscription_ratio=1.0 reserved_percentage=5 В фале nfs_shares_config указываю, соответственно: <filer ip>:/share При этом <filer ip> это mng адрес nfs-сервера, а основной data-траффик (например, к гипервизорам) должен ходить по другой выделенной 10g сети. Я указываю этот filer-ip потому, что cinder-volume требует доступа к шаре и создаёт там какие-то файлы. Но при создании и подключении волума я вижу, что волум монтируется на гипервизор по этому самому адресу, что печально - большой траффик идёт по mng сети. В доке нигде не указано, что cinder-volume требует доступа к этой nfs шаре, что он создаёт там какие-то файлы и т.п. Зачем ему это нужно ? Я бы указал вместо <filer ip> адрес storage интерфейса nfs-сервера, так бы корректно выполнялось монтирование шары на гипервизоры. Решение я вижу в том, что нужно добавить на сервер с cinder-volume ещё один интерфейс, который бы смотрел в storage-сеть, но может быть я что-то не то делаю? Вот картинка с описанием траффика и никакого data-path к cinder-volume на ней нет: https://lh5.googleusercontent.com/proxy/DQp_j0pyCjoO5p_xfPZpcvHyJbNf5IMYupgXpJ-zeFNXZ54jN2zOn3566lh_Lkb1B4nezmZCmQr19brZCfxhhfzymXGMerM9576bXbGtLOZEF7mMYF0JEmPuZkg2JRJJD4wZ6n-L43YHIkREy5V2wefKPzckuskxBF2FDFB2oNqGCk8Jpnk=w5000-h5000 Вот ещё одна:

@apostolpavel посмотри плиз

коллеги, а кто настраивал регистрацию и резолвинг ВМ в dnsmasq Нейтрона или как-то еще решал этот вопрос без Designate?

коллеги, а кто настраивал регистрацию и резолвинг ВМ в dnsmasq Нейтрона или как-то еще решал этот вопрос без Designate?

Не флейма ради спрошу, чем не подходит. designate?

по мнению опрошенных специалистов designate - продукт сырой и в моем случае можно ожидать от него больше неприятных сюрпризов, чем приятных

по мнению опрошенных специалистов designate - продукт сырой и в моем случае можно ожидать от него больше неприятных сюрпризов, чем приятных

Вы корпорат или провайдер?

первое

Тогда вопрос шире, как наиболее просто перехватывать и обрабатывать событие создания инстанса, чтобы регистрировать его где нужно, будь то DNS или Cmdb. Я только запускаю OS, но уже предвижу необходимость решения этих задач.

поддерживаю!

не хочется делать костыли к Нове, если можно обойтись подкруткой dnsmasq

Ddns имеется ввиду?

да

Я представляю себе только dhcp exit hook для dhclient на самом инстансе, который вызывает nsupdate.

функциональный вариант, но слишком зависит от того, в каком ресторане сегодня обедал админ хоста

Ну я потому и спросил, корпорат или нет, рута не давайте на инстансы. :)

низя

рут есть, зато много вырезано из имиджа - только руки, ноги и прямая кишка осталась

но он этой кишкой понаделать может…

Я думаю, что хуки в dnsmasq не помогут, инстанс получает адрес раньше, чем меняет хостнейм, на dhcp сервер прилетает localhost или что там зашито в имейдже.

@ITD27M01 , спасибо! это важный момент.

Коллеги, по поводу регистрации событий создания - удаления инстансов посмотрите на механизм нотификаций.

Их использует в частности ceilometer и другие проекты (например StackTach3 от Rackspace)

В общем это штатных механизм

Oslo.messaging

Илья, Александр, спасибо!

@ITD27M01 , хост разворачивается при помощи мурано, поэтому агент может в нем кое-что подправить перед dhcp

@ITD27M01 , хост разворачивается при помощи мурано, поэтому агент может в нем кое-что подправить перед dhcp

Не факт, Мурано же через агента действует на хосте, наподобие cloud-init

мурано это только интерфейс, инстансы развёртывает heat. В любом случае cloud-init начинает свою работу только после того, как получил адреса.

> @adiantum Не факт, Мурано же через агента действует на хосте, наподобие cloud-init да, вот агент на хосте перед получением IP у dhcp может вместо localhost прописать назначенное юзером имя машины

мурано это только интерфейс, инстансы развёртывает heat. В любом случае cloud-init начинает свою работу только после того, как получил адреса.

тоже верно

Агент его не сможет получить до тех пор пока сеть не будет настроена

Агент его не сможет получить до тех пор пока сеть не будет настроена

да, ерунду предложил, согласен

Привет новеньким )

а настоящий почему не забил в колокола?

А я и не знал что у вас тут такие технологии есть

мы не туда)

Сергей, кинь номер в личку - добавлю

Дарова, пасаны! ?

хеллоу

Приветствую всех)

@adiantum , @ITD27M01 продолжаем разговор :)

http://alesnosek.com/blog/2015/05/31/openstack-dynamic-dns-updates/

похоже на правду?

Угу, как раз упоминается механизм нотификаций

Я видел, я думаю, что это правильный способ. Из этих нотификаций можно вытягивать всю необходимую информацию. Вопрос только в том, что за сервис будет "следить" за событиями.

Я видел, я думаю, что это правильный способ. Из этих нотификаций можно вытягивать всю необходимую информацию. Вопрос только в том, что за сервис будет "следить" за событиями.

celery worker

Сервис придётся самим написать

celery worker

куда ж без него

Celery не факт что подойдёт

Celery не факт что подойдёт

почему?

https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/server.py#L300

Вот это за основу можно взять

У celery свой формат эвентов

подойдет. нет необходимости писать службы, один скрипт и пару настроек

+ dispatcher с endpoints

А вот oslo.messaging да

И нужен именно сервис, чтобы перехватывал события