nocproject.org

Привет

Кто-нибудь знает как сделать так, чтобы link down не попадал в алармы?

PavelGloba: профиль интерфейса настроить например

вот как бы сделать чтобы он туда попадал...

я подумал просто изменить warning на info, но нок не даёт это сделать

кто в ansible разбирается?

Что именно в ansible надо? Не скажу что сильно разбираюсь, но поищу..

https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/?at=feature/microservices

я начал портировать bootstrap + upgrade в ansible

пока делаю только под debian

нужны будут порты и на другие платформы

,,

Сделаю порт на Gentoo.

https://cp.nocproject.org/p/Elhd

я вот так делаю

это конфиг для vagrant

Речь о создании образа виртуальной машины или о управлении распределёнными узлами NOC посредством ansible?

Это не универсально: https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/roles/activator/tasks/main.yml?at=feature/microservices

речь идет о том, что NOC будет разворачиваться и апгрейдиться через ansible

на любом количестве нод

Да я понял но при чём виртуальные образы?

Есть установки NOC которые pip не используют вовсе и virtenv тоже...

Тоесть всё рулица полностью стандартным менеджером пакетов.

если ты про vagrant, то это просто пример

как можно запустить несколько виртуалок, чтобы накатить на них playbook

установок, которые не используют virtualenv и pip, считай, что нет

По этому использование pip в main.yml https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/roles/activator/tasks/main.yml?at=feature/microservices не очень универсально.

это неподдерживаемая конфигурация

почему не универсально?

Желательно pip и прочие менеджеры пакетов использовать уровнем выше, где есть конкретика дистрибутива.

да нет, как раз внутренние детали pip скрывает

чем системные пакеты лучше pypi?

В некоторых дистрах менеджер пакетов знает внутринние детали и зависимости NOC? ему pip не нужен!

что-то я в это не верю :)

А в некоторых дистрах менеджер пакетов NOC не знает, там нужен дополнительно pip и rjcnskb бутстрапа...

откуда менеджер пакетов узнает про noc?

Убедись: https://bugs.gentoo.org/attachment.cgi?id=408790 там NOC/net-analyzer/noc/noc-15.05.1.ebuild вообще не использует pip, hg, virtualenv.

Даже для noc-pkg зшз не испошльзуется.

И если профиксить: NOC-1523 то развёртование удалённых активаторов тоже заработает без .hg

а файлы из noc-pkg как тащишь?

развертывание удаленных активаторов через ansible делается

ebuild там всё тащит в зависимостях.

NOC, теоретически, должен устанавливатся и настраиватся штатными средствами OS! Это идеал...

в microservices нет вообще такого понятия, как удаленный активатор

есть ноды

на нодах крутятся сервсиы

поднимаешь еще ноды и запускаешь на них пул активаторов

а куритизанки где?

куртизанки

Но, пока, разрабы дистров не поддерживают его пакет мы используем костыли: pip, hg, virtualenv.

Вот всё что имеет эти костыли желательно вынести в часть OS зависимую..

https://pp.vk.me/c625822/v625822151/39cef/n82c20qqEHg.jpg

xetle: насколько я знаю, только gentoo сейчас содержит пакеты

да и не суть важно

dvolodin: хотябы к hg гвоздями эту реализацию microservices.

e_zombie: это скрытый продакт-плейсмент!

прибивать не надо...

xetle: она не прибита

точнее -- прибита в части вытаскивания апдейта

https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/roles/node/tasks/main.yml?at=feature/microservices#main.yml-14

вот тут

в 14 строке

больше там нигде нет его

В develop прибит hg намертво! Ибо без него удалённый активатор не сделаешь.

там да

Вот!

В microservices, пожалуйста, так не делайте.

в microservices только в одном месте есть hg

там, где вытаскивается репо

теоретически, там можно как-то сконфигурить

Да, только в script/upgrade где обновляется основной репозиторий должен быть hg.

В остальных местах держать его - зло.

Да, в upgrade.conf если BRANCH=none оно эту ветку кода пропускает. Так и должно быть!

То есть hg только в script/upgrade и возможность его отключить в upgrade.conf если BRANCH=none

scripts/upgrade больше не будет

Еще раз повторюсь, желательно ansible весь код связанный с pip, hg, virtualenv выносить как дистрибутиво зависимый.

насчет virtualenv я не уверен, что прокатит

И чтотам будет теперь апгрейдить, пусть имеет возможность отключить hg в upgrade.conf если BRANCH=none

Пока без virtualenv работает нормально.

Я лично virtualenv и pip считаю временным костылём, заменяющим работу стандартных менеджеров пакетов дистрибутивов...

а я, скорее, наоборот

менеджеры пакетов - костыль

:)

В Gentoo поддерживается два вида установки: стабильный noc-15.05.1.ebuild без virtualenv, hg и pip и для разработчиков-тестеров noc-9999.ebuild с virtualenv и pip и апдейтом по hg.

pip - менеджер пакетов, да костыль :)

Стандартный менеджер пакетов в дистрибутиве - необходимая его часть для установки и обновления ПО.

Стандартный менеджер пакетов дистрибутива - не костыль, а необходимая тулза!

xetle: костыль по одной простой причине

во всех дистрибутивах они разные

:)

с точки зрения производителя софта при выборе между pip'ом, который один на всех, и всякими deb/rpm/pkg/ebuil лесом пойдут последние

или в лучшем случае будут только rpm, и иногда - deb

ладно, это holywar уже

если аргументировано

NOC - кластерная система, которая может крутиться на большом количество нод

менеджер пакетов -- понятие в пределах одной ноды

в одной конторе может быть несколько кластеров

например -- по филиалам

или отдельный тест

у них разная политика обновления

кто-то из develop обновляется

кто-то по стабильным версиям

кто-то из feature

ноды могут быть на разных системах

чтобы не двинуться совсем с этой конструкцией - будет башня

в которой можно будет все это безобразие конфигурировать

и она будет запускать этот playbook

"с точки зрения производителя софта при выборе между pip'ом, который один на всех, и всякими deb/rpm/pkg/ebuil лесом пойдут последние"

"точка зрения, зависит от точки сидения..."

С точки зрения разрабов дистров, прибивка гвоздями всяких внешних менеджеров пакетов создант весомые трудности при создании стандартного пакета.

Это надо помнить производителям софта и pip, hg, virtualenv использовать только в ДИСТРИБУТИВО ЗАВИСИМОЙ ЧАСТИ КОДА.

Я убеждён, что РОДНЫЕ пакеты в дистрибутивах такого уникального проекта как NOC будут появяляться.

Возвращаясь к теме pip с https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/roles/activator/tasks/main.yml?at=feature/microservices надо переместить в https://bitbucket.org/nocproject/noc/src/87097ca398d6dc8a82620e264d1b52681f6ef30b/ansible/roles/activator/tasks/os/Debian/main.yml?at=feature/microservices

xetle: pip - стандартный менеджер пакетов для питона

кроссплатформенный

dvolodin: я тут продакшен собираюсь собирать. микросервисы уже "живые" или пиздетц ?

да, но стандартные менеджеры пакетов для OS ставят и все питоновские модули и всё остальное. Причём стандартные менеджеры пакетов для конкретной ОС делают это учитывая её политику и кучу прочих вещей..

я с таким рассчётом чтобы к октябрю выйти на продакшен но при этом избежать процесса апгрейда

e_zombie: они не менее живые, чем develop, в общем-то

подожди немного - доделаю башню и playbook для установки

к октябрю точно на продакшен выйдем

dvolodin: при обсуждении NOC-1523 говорил уже это всё. Разраб должен дать пакет и список зависимостей. Остальное дело разрабов дистров и их менеджеров пакетов.

xetle, системы пакетов неидеальны

да и что?

ну я так и подозревал

xetle: тут один изъян

а то что зацикливаться на них нет смысла

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

а у нас выбор простой

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

причем сильно тормозить

Нет, все сразу не рванут. Но им надо дать шанс!!!

и отвлекать дополнительные ресурсы

или игнорировать их требования, как не соответсвующие нашим интересам

первична система управления, а не дистрибутив

в принципе, какой надо дистрибутив, такой и поставят

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

вчера пытался поставить на комп чат клиент, а он требует sqlite собраный без secure-delete, а тандерберд наоборот, требует secure-delete, и все, две программы на один комп не поставить, справишвается что за херня. Весь линукс с его системой распростране

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

zi_home: да, это RPM hell

Я нивкоем случае не отменяю текущей ситуации с скриптами установки pip, hg и virtualenv. Я просто говорю что этот, временный костыль, вынести в ДИСТРИБУТИВО ЗАВИСИМУ ЧАСТЬ КОДА!!!

я потому и делаю virtualenv и ставлю то, что мне нужно

а не то, что есть в дистре

dvolodin, это гента

xetle: я тебя услышал

только наоборот сделаем

:)

если branch = none, оно не будет работать

и пусть работают системные пакеты

но с здоровой красной надписью, что это не поддерживается и ебите мозг вашему локальному дилеру дури :)

dvolodin: вот что мешает при разработки установки с нуля в microservices всё что связано с pip, hg и virtualenv вынести в ДИСТРИБУТИВО ЗАВИСИМУ ЧАСТЬ КОДА?

не

Я готов помочь..

дистрибутивонезависимую

смотри

этот код работает для debian/ubuntu/rhel/sles/opensuse/freebsd/osx

и не должен работать для gentoo

по теории относительности -- ответвлять нужно gentoo'шную часть

а в этой вставить что-то вроде

when: "{{noc_branch}} != 'none'"

если появятся нативные пакеты в дистрибутивах

xetle, а что конкретно ?

то можно будет там в дистрозависимой части их ставить

и ты говоришь только про пакет для генты ?

Нето:

и прописать там when: "{{noc_branch}} == 'none'"

и будет счастье тебе

если branch - none

то не будет работать pip

{{noc_branch}} = 'none' - должен отключать обновление по HG и только!

но будут рабоать пакеты

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

у тебя в башне в политике обновления будет

Введи ещё переменную packetmanager

либо использовать hg, либо дистрозависимые костыли :)

dvolodin, а вообще много инсталяций на генте ?

freeseacher: 1

:)

а есть сводка под осям ?

packetmanager=pip - работают скрипты

packetmanager=none - или ещё что, неработают скрипты, а только стандартный менеджер пакетов.

xetle, на самом деле самый клевый вариант распрастранение в виде докерных контейнеров.

полностью готовая среда.

не надо ничего пилить

прям как в винде

поддерживать надо только один дистр

freeseacher: генту использую я лично. Моет ещё кто, ебылд в инете висит...

я не против же.

гента так же имеет право на существование как и калибри

просто мождель распрастранения при которой тебе единственной зависимостью выставляется версия ядра - выглядит гораздо более интересно

да, есть

с другой стороны.... freebsd, osx.

freesearcher да не дай бог такое

фряха довольно распрастранена. а без osx низя. дима на ней пишет.

и виндовс не забывай

freesearcher контейнеры

freeseacher, dvolodin: считаю что вы спривязкой к pip контейнерам и прочем... желая упростить установку и распространение NOC в реальности её только замедляете!!!

zi_home, нок постаивть на форточку нези афаик

Дайте шанс дистростроителям собрать найтивные пакеты для NOC!!!

ну не знаю, вроде питон под винду есть

остальное приложится

zi_home: венда не нужна

zi_home: нет смысла поддерживать винду

Давайте ограничимся Юникс подобными и только.

debian/ubuntu в лидерах по распространению

затем с сильным отрывом фря

и чуть меньше - centos

+1 на гентоо ;)

dvolodin, соляра ?

так ее даже кде закопал

dvolodin: мешает при разработки установки с нуля в microservices всё что связано с pip, hg и virtualenv вынести в ДИСТРИБУТИВО-ЗАВИСИМУ ЧАСТЬ КОДА?

соляра есть одна

:)

она же - инсталляция #1

:)

xetle: мешает относительность

оно работает везде, кроме gentoo

:)

пока картина не изменится, придется делать наоборот

Вот захотят deb или rpm пакет сделать так не смогут опять...

Дайте шанс дистростроителям собрать найтивные пакеты для NOC!!!

deb пакет чего?

смотри

gmp нужен только если на ноде есть активатор

Репозиторий deb пакетов самого noc и его зависимостей которых нет в стандартных портах...

Надо дать возможность дистрам сделать нармальную установку NOC хотябы на мастер ноду.

Дальше пусть ansible рулит на других.

Но ansible тоже на других нодах должен учитывать их ОС

Тоесть разделять независимую список пакетов, настройки,... и ДИСТРИБУТИВО-ЗАВИСИМУЮ часть - установка пакетов.

xetle: да нет такого понятия как мастер нода

они все равноправны

отнюдь

когда делаешь make-node

все отсальные синхрятся с центром

Хорошо, вынести всё что касается установки пакетов в ДИСТРИБУТИВО-ЗАВИСИМУЮ часть кода.

zi_home: раньше так было, может теперь и ноды равноправны...

тогда нужен фул меш

а его точно нет

хз, может там уже в микросерверах ии есть ;)

Камрады, всем здрасьте. А что там за ansible появился в трекере? Для каких целей его прикрутили?

да это dvolodin жиру бесится

ну эт понятно

вместо чтобы баги фиксить

))))

Night_Snake2: если много установок NOC то ими управлять будет.

а много это с учетом выносных активаторов синков и проб

или не?

помтоу что если не, то это печально

много это сколько? И что есть "установка NOC"?

весь? или как zi_home сказал?

никто не знает Ж)

zi_home: да, говорят, все выносние активаторы пробы и прочие теперь управлятся через ansible будет.

куда не шло

ни*

ну если так то да

норм

главное, чтобы это работало)))

хотя по мне так стоит посмотреть на опыт других систем

а что с probes? его переписали как-то?

там выносной агент это отдельный пакет

Главное чтобы ПРАВИЛЬНО работало и ПРАВИЛЬНО реализовано было... ;)

ansible хорош тем что без агентный, по openssh всё работает.

вся инсталляция через ansible будет рулиться

н-да

,,

Как заставить mercurial не проверять сертификаты при ./scripts/upgrade ?

А то получаю: SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

?

In-nick: не должно такого быть. Может у тебя hg с openssl протухли в системе..

In-nick, обнови mercurial

обновить ссл

e_zombie: Ты про openssl ?

каступю что да.

In-nick: hg для шифрования использует внешнюю библиотеку openssl. Её надо обновить, но возможно также и hg придётся обновлять, зависит от изминений API.

не надо там ничего обновлять кроме меркуриала.

Вот менеджер пакетов дистрибутива это должен определять..

нет возможности обновить меркуриал... есть какие-то другие способы обхода?

In-nick: оно питоновский ссл берёт в этом месте: /usr/lib64/python2.7/site-packages/mercurial/sslutil.py

надо в твоём дистрибутиве обновить меркуриал с его зависимостями.

Что лучше 1 инстанс активатора на 100 скриптов или 2 по 50?

если у тебя один цпу то пофиг

один цпу в наше мирное время- не бывает

ну таки смотри сам.

если у тебя будет слишком много параллельно работающих процессов у тебя будет переть лоадэверейдж на серваке что не есть айс

короче море нюансов.

на LA пофиг

тут ты не шибко прова

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

ну ну.

e_zombie: чтоб нагнать серьезный LA надо заведомо неразумное число инстансов

достаточно иметь большую сеть и врубить опрос аптайма раз в минуту

и у тебя такой пиздетц будет.

он будет с ожиданием свободного инстанса а не с ЛА

Подскажите пожалуйста, при попытке очистки базы в монге наблюдаю следующую вещь:

> db.noc.log.sa.failed_scripts.remove();

2015-08-24T15:42:04.237+0300 remove needs a query at src/mongo/shell/collection.js:299

Файла такого в системе вообще не нахожу, откуда его можно подтянуть?

db.repairDatabase();

это работает, заканчивается с кодом 1

попробуй тормозни нок и ребутни монгу.

4 активатора, по 500 скриптов дают LA ~0.5 при version inventory на ~5К железок

ну как говорится - бог в помощь.

плодитесь и размножайтесь

Это на 4 CPU

там примерно 200 железок неживые. когда пошли таймауты - подросло до 0.7

ребуты и не помогли

kokozzi: http://stackoverflow.com/questions/25104095/remove-needs-a-query-at-src-mongo-shell-collection-js

посыпаю голову пеплом и иду учиться гуглить самостоятельно

большое спасибо)

dvolodin: а есть какие-либо принципиальные возражения против того чтобы version inventory и аналогичные запуски скриптов автоматом обновляли sa attributes?

а они что делают?

они и обновляют

e_zombie: не обновляют

хостнеймы и тд да. не обновляют.

а атрибуты обновляются.

get_version собирается, выдается на экран, но в базе остаются старые значения

а он и не должен

ты определись - обновляют, или не обновляют)

при запуске дебага так же это не обновляет

когда оно у тебя запускается через активатор - обновляет

Version inventory - это как бы не дебаг

во всех других случаех - только вывод

и оно _всегда_ запукается через активатор

ну вот сегодня утром у меня было массовое обновление прошивок на свитчах. В базе ессно сидят старые данные. И быстрого разумного способа их обновить я не вижу

причем в Sa -> object -> Discovery для version_inventory стоит last status - Fail. при том что оно работает

а что говорит дебаг

?

e_zombie: дебаг чего?

/noc debug-script get_version asw2-72-eng

все нормально там

тогда почему фейл?

свитч честно отдает даные

вот я б тоже хотел знать почему фейл

Всем привет! Товарищи, я уже спрашивал у вас про то, как построить в веб-интерфейсе иерархию из произвольных обьектов, мне посоветовали использовать селекторы, но я ничего не понял. Хотелось бы в веб-интерфейсе видеть страничуку проектов и кликнув

на название проекта проваливатся во все адрсе\сети ему принадлежащие. Как это сделать??

вот ты накинул проблемку

Вроде как логическое разделение, а не по подсетям. Это вообще реально в noc ?

Ultra4: да. селекторами

но муторно

можно ещё забодящить административными доменами. и потом сделать селектор с выборкой только по этому административному домену.

ну или по сегментам.

такое тоже можно сделать .

filonov: А можно поподробнее, я раньше не работал с noc. Документацию почитал но понимания не прибавилось.

/main/desktop/#sa.administrativedomain

Ultra4: могу только посоветовать читать до тех пор, пока понимания прибавится

тут фигачишь свои домены. - потом ставишь их в карточк МО

но лучше сегментами

main/desktop/#inv.networksegment

filonov: Можешь хотябы показать какой это раздел документации?

Потому, что слово селектор я в интерфейсе увидел, а каки их создать - нет.

Sa -> setup -> Managed object selector

filonov: Спасибо

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

e_zombie: Таааак, сейчас попробую, а сам селектор применяется к интерфейсу где?

ээээ

а селекторы используются везде где у тебя надо выбрать какие то объекты или отфильтровать вывод.

у тебя в СА - МО есть поле селектор тоже.

можешь там потренироваться

начни с спростого. напиши регекс для имени.

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

e_zombie: Это, насколько я понял, для оборудования, а мне надо для сетей

у тебя потом сегменты так же опираются на селекторы.

/main/desktop/#inv.networksegment

но это для построения иерархии

e_zombie: Вот я прописал теги, сделал селекторы, но не могу понять как его использовать

Оу, вейт

А не проще ли это просто через Projects сделать

нененене

e_zombie: Почему?

самое гибкое решение - это через селекторы.

а параметры кто куда ...

это уж как тебе нравится

Так, окай, вот у меня есть готовый селектор, куда мне зайти, чтобы отфильтровать по нему сети?

/main/desktop/#sa.managedobject

у тебя там есть фильт - селектор

У меня там только один обьект - некоторое дефолтное SAE

у тебя вообще чтоли ничего не добавлено?

e_zombie, у меня добавлены только сети

Я не планирую использовать noc как базу для инвентаризации

Да и в поле adress там влезает только один ip

народ, а nag свитчи у кого-нить работают корректно? подключил snr-2950 и snr-3750 get_version летит, на get_interface ошибка. куда копать? noc только вчера поставил) доку читаю

Ultra4: https://kb.nocproject.org/pages/viewpage.action?pageId=19169410 сделай вот это для начала.

тогда у тебя будут все хосты.

хотябы всегда.

talyan: ./noc debug-script get_version asw2-72-eng

и смотри на чём оно валится. потом идёшь и пишешь багрепорты.

e_zombie: Я понял, но мне вообще не нужны хосты, мне надо только по тегам фильтровать сети

если у тебя нет МО объектов то фильтровать тебе просто нечего .

ибо ты даже собрать инфу об адрессном пространстве с оборудования не сможешь.

если я тебя правильно понимаю.

e_zombie: Я же могу руками добавить Allocated Prefixes и ставить на них теги

Show free prefixes

есть объекты МО --> можно с них сдёрнуть VC\VRF --> адрессный план и тд.

e_zombie: Ну т.е если бы сортировал по МО, то я получил бы сами железке на выходе?

да.

но

А мне нужны сети, а не железки

если у тебя в МО есть твои ПЕ с которых ты можешь снять адрессные планы то ты получишь что тебе надо.

через жопу но получишь.

Понял, я подумаю про сбор данных с оборудования, а пока мне подойдет способ через Project

лучше делай сразу с оборудования.

это у тебя будет работать автоматом.

и без участия человека.

если есть человек == бардак и анархия

А кому денег занести, что бы в Project дескрипшены сетей показывались?

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

или ищи знакомого кто напишет.

вот типа такого NOC-1616

О, спс!

https://www.deliberant.com/ru/wnms

Что-то нигде не нашел возможности задонатить

и не найдёшь.

потому что доната нету.

делай багу и потом проси володина так сделать .