nocproject.org
03:59
dvolodin привет
03:59
какую-нибудь бы статейку или хотя бы картинку по новым фишкам с сервисами и прочим...
03:59
а то, например, не ясно: может же на свитче доступа быть несколько service terminator?
03:59
например pppoe там и ipoe... а может и voip
04:00
и все по разному терминируются
04:00
технология определяется портом
04:34
с voip немного по-другому
04:34
service terminator будет установлен у телефонного шлюза
04:42
я думал у шлюза будет termination group...
04:43
а на примере IPoE? терминатор - это всё-таки шлюз для юзера (свитч агрегации) или брас, где уже всякие isg
05:02
termination group -- на BRAS
05:02
а service terminator -- ссылка на BRAS на свичах доступа
05:12
05:12
вот радикальный ответ на твою хотелку "отключить alarm jobs'ы нах"
05:13
оно же -- замена alarm и event trigger'ов
05:13
суть очень проста
05:13
делаешь свой solution
05:14
в noc.lib.solitions появились функции {register,unregister}_{event|alarm}_class_handlers и {register,unregister}_alarm_job
05:14
добавляешь их в __init__.py solution'а
05:15
05:15
как-то так
05:16
тебе нужно unregister_alarm_job("Network | Link | Link Down", "check_link")
05:16
и он отключит тебе job
05:16
там же можно донавешивать свои обработчики
05:19
05:20
указать handlers в event classs
05:20
тогда он будет безусловно ребутить железку
05:20
или в своем solution'е донавесить перезагрузку
05:40
нате товарищи скриптописатели вам новый интерфейс для полезного скрипта reboot
05:40
:)
05:40
05:40
06:28
хехе
06:28
Дима опять солюшены наворотил
06:28
а второй Дима будет безусловно рад)
06:34
я уже впечатлился.
06:34
мы опять гланды вырываем через жопу и автогеном
06:35
т.е вместо возможности запретить запускать этот джоб, мы его запускаем, а потом прибиваем эту задачу
06:35
Я столько не выпью, чтобы разобраться влогике Димы
06:36
Я чувствую, что для IPAM он сделает аналогично
06:37
Вместо того, чтобы запретить собирать "левые" IP адреса, он сделает солюшн, который их будет раз в час вычищать из базы
06:37
на самом деле этот джоб полезная вещь, надо просто оптимизировать его поведениенапример увеличивать периоды, если аларм должго висит
06:38
или если для МО не используется снмп то проскать каждую вторую проверку
06:38
zi_rus: Должна быть возможность управлять им. Т.е., хочу - включаю, хочу - отключаю
06:39
это базовая функция ФМ, она сделана не от нехуй делать а по определенной причине
06:39
отключение это очень серьезный шаг
06:39
Эта "базовая функция" прибита гвоздями, что не должно быть
06:40
некоторые линки могут лежать годами, а проверять раз в минуту такие нет смысла
06:40
Программа не должна выполнять каких-то действий, если об этом не известно пользователю
06:40
иногда программа вынуждена делать то о чем юзер и не подозревает
06:41
это назывется автоматизация
06:41
Такие программы называются "трояны" и "вирусы"
06:41
если ты прочитаешь доку ты поймешь что программа делает
06:41
это не скрытая функция а вполне явная
06:42
Эта "явная функция" вмешивается в работу сети, которая обслуживает десятки тысяч абонентов.
06:43
эта функция безобидно выполняет одну команду
06:43
раз в какое-то время
06:43
так же поступает бгп, оспф, стп
06:43
Написали бы в документации NOC, что ставить его только на Cisco, JUNIPER и Force10. И я бы даже не пытался с ним что-то делать
06:44
вмешивается в работу сети
06:44
=)
06:44
почему ущербность длинка это проблема нока?
06:44
трахай длинковский саппорт, почему у них снмп кривой
06:44
кстати
06:45
у них же есть своя система управления
06:45
dlink view кажется
06:45
Проблема NOC'а в том, что он без моего ведома заходит на железку.
06:45
в ноке еще есть куча дискавери активированных по дефолту, они тоже без твоего ведома?
06:45
да
06:46
тот же get_interfaces и get_inventory
06:46
у меня оборудование стоит в одном месте годами с неизменными настройками
06:47
И я не нашел, как запускать эти скрипты по моему хотению, а не по хотению NOC
06:47
смотри сислог и трапы
06:47
_4ePTeHok: Я не о том
06:47
Вот в NOC есть штатный пункт меню: "version inventory"
06:48
Я могу запустить собирать get_version с железок вручную, причем с тех, которые я хахочу
06:48
можешь
06:48
даже автоматом
06:48
Таких пунктов для get_interfaces и get_inventory нету
06:50
Interface discovery
06:50
06:50
06:50
Asset discovery
06:50
это что?)
06:50
заходишь в профиль
06:50
отключаешь что не надо
06:51
выставляешь интервал минимальный и максимальный когда
06:51
бля.
06:51
что мешает тебе профиль выставить для всех нужных тебе объектов7
06:51
Для селекторов есть только "Run Map/Reduce Task", но совсем неочевидно, как им пользоваться
06:52
а руками потом запустить можешь после навешивания профиля - выделив в sa-mo нужные объекты и ткнув дискавери нау
06:52
селектор не для дискавери
06:52
дискавери ограничивает работу профилем объекта
06:53
ты выдумал эту проблему
06:53
Извини за выражение, но это "хуйня"
06:53
Смотри мою логику
06:53
У нас есть get_interfaces. который выдает список интерфейсов и их состояние
06:54
Интерфесы есть "физические", "логические" и туннель
06:54
текс
06:54
ребя что делать с такой штукой
06:54
новая установка
06:55
все прошлые глюки поборол
06:55
однако
06:55
Error: lookup for noc.alarmclasses.name == 'Network | Link | Link Down' has been failed
06:55
upgrade-user: 45: collection --sync failed
06:55
Terminating
06:55
Почему бы не запускать get_interfaces при ивенте "link up", если в базе этого логического интерфеса нету или физический был в состоянии "down" ?
06:55
RudW0lf: это к dvolodin
06:56
блин, вот ты опять с одного на другое перепрыгиваешь
06:56
ты сказал - хочу запускать геи инвентори когда хочу и для кого хочу, а НОК не дает!
06:56
Почему? Где у меня не так с логическими рассуждениями?
06:57
Да. А NOC без тлоку гоняет эти скрипт даже тогда, когда ничего не меняется на железке годами
06:57
я тебе показываю, что этот инвентори работает так же как и сбор конфигов и версий - в профиле объекта включаем, настраиваем интервал, цепляем за объекты.
06:58
не хотим дергатни - ставим там хоть год
06:58
Вспомни логику работы get_config
06:58
стоп стоп
06:58
ты пару строк назад ругался, что не хочешь чтобы нок лазил
06:58
сам
06:58
когда конфиги можно было заставить собираться только при ивенте "config saved"
06:58
а теперь - говоришь что нужен джоб, который будет лазить проверять сам при каком то событии
06:58
что за чушь понаписали
06:58
задачу никто не прибивает
06:59
если alarm job отключен из solution'а, коррелятор просто не будет его запускать
06:59
Т.е. я мог отключить выполнение джоба "get_config", а заставить его выполняться тольео при ивенте "config saved"
07:00
Dmitry1, не очень логика.
07:00
а если евент был потерян ?
07:01
или его железка просто не отдает
07:01
что плохого, что раз в день noc перепроверит конфиг
07:01
в ивенттриггере и алармтриггере я могу ваставить СЕЛЕКТОР !!!
07:01
И запускать pyrule для определенных железок
07:02
Т.е. для каких-то я хочу собирать конфиг каждые 5 минут, а для каких-то только по ивенту
07:02
Так же должно быть и с check_link
07:03
бля.
07:03
настрой профили уже
07:03
дим
07:03
делается это в настройках managed object profile
07:03
причем элементарно
07:04
поставь на сonfig_discovery max time в 100 лет
07:04
и будет оно у тебя только по event'у ходить
07:04
я это знаю
07:05
как мне то же самое сделать для check_link
07:05
без использования solution
07:05
чек линк работает как раз по ивенту
07:05
т е это ситуация то другая
07:05
ну т е по алярму
07:06
get_config тоже работает по ивенту
07:06
через ивенттриггер
07:06
но там ты просишь как раз оставить по ивенту - а тут наеборот - отключить
07:06
ивенттриггером и алармтриггером я могу управлять
07:07
солюшеном по идее тоже)
07:07
надо только знать как
07:07
включить/отключить, привязать его к селектору, выполнять его только в определенное время
07:08
Например о том, что я вчера гоаорил
07:08
dvolodin, Дим, сделй плиз пример какой нить с объяснением для солюшенов
07:08
Все уже реализовано в триггерах
07:08
И меня оно устраивает на 110%
07:08
Вспомни вчерашний разговор
07:09
Мне нужно отключить check_link на ночь и на выходные дни
07:09
В триггерах уже предусмотрен "time_pattern"
07:11
dvolodin: Дим, объясни мне, пожалуйста, почему ты не хочешь вынести некоторые части NOC в триггеры?
07:11
потому что это костыли
07:12
ты потом запаришься поддерживать их
07:15
dvolodin, кстати про триггеры тебе правильно говорят, есть куча ивентов на которые можно реагировать, get_inventory на Transciever inserted запускать вполне логично.
07:16
а вот еще
07:16
dvolodin: А что там поддерживать? Включил/отключил
07:17
dvolodin, почему нок для железки которая вернулась из ребута, дергает конфиг, но не удосуживается дернуть версию софта. конфиг от ребута меняться не должен а вот версия софта вполне
07:18
А теперь расскажи новичку в NOC: (цитирую тебя)
07:18
noc.lib.solitions появились функции {register,unregister}_{event|alarm}_class_handlers и {register,unregister}_alarm_job
07:18
добавляешь их в __init__.py solution'а
07:18
"unregister_alarm_job("Network | Link | Link Down", "check_link")
07:18
Звучит как минимум, как китайская грамота
07:19
а как же мотивировать людей покупать саппорт :)
07:20
zi_rus: погоди, он все процессы discovery сдвигать должен
07:21
dvolodin: Дим, я не против там всяких workflow, solution и т.п.
07:21
zi_rus вот как раз конфиг может поменяться, если кто-то его не сохранил, и на это нужно быстро реагировать
07:21
Но во первых, их должно быть куча в БАЗОВОЙ поставке NOC
07:22
Во - вторых, должен быть человеческий способ управления ими
07:22
Пусть в ивенттриггере я буду включать/отключать не pyrule, а solution
07:22
lexus-omsk, теоретически, да, но например в IOS XR не надо ничего сохранять, конфиг сохранен всегда, но да, после смены софта формат файла меняет и дифф действительно приходит
07:25
то же и в junos
07:25
конфиг от ребута вполне может поменяться, как сам по себе, так и от версии софта
07:25
Дим, никто кроме тебя не знает, как работают solutions
07:26
никто кроме автора этих solutions
07:26
блин
07:26
это обычный питоновский модуть, его __init__.py выполняется при запуске
07:26
что еще надо из знаний?
07:26
dvolodin, вчера на одной ASR9k обновил софт, новый конфиг почти сразу пришел, а новую версию пришлось сегодня руками запускать
07:27
что ты будешь делать в этом init -- твое личное дело
07:27
кроме того, есть веревочки, чтобы поменять настройки
07:27
типа сегодняшних функций
07:28
не понимаю. упорно
07:28
где эти функции должны быть?
07:29
В web морде ничего не отображается
07:29
да хоть какие-нибудь?
07:30
посмотри solutions/noc/discovery
07:30
обычный модуть
07:30
его функции ты указываешь в конфиге
07:30
там где есть возможность выбора
07:31
и в его __init__.py ты можешь прописать что угодно, что будет выполняться при загрузке
07:32
блин
07:32
ты совсем не туда полез
07:32
забуть про WF
07:32
я нормальный человек. Там написано "Solution"
07:34
zi_rus: "конфиг от ребута меняться не должен"
07:34
а может, конфиг берется текущий, на длинках так, по крайней мере
07:35
хер с ним с конфигом, я про то что смена конфига менее вероятна чем смена софта, тем не менееконфиг собирается а версия нет
07:35
я не против сбора конфигпа
07:35
я за сбор версии
07:35
dvolodin: кто кроме тебя знает, что выполняет solutions/noc/discovery ? Как им управлять можно?
07:39
Это мне напоминает разработку ядра для OS. А у нас в кернеле появилась новая функция "сделать все лучше в 10 раз", но как она называется мы не скажем, каие параметры туда передавать и что она возвращает это секрет, из юзерлевела ее невозможно вызвать
07:39
zi_rus: присоединюсь
07:40
уважаемые разработчики, а как бы с линк_дискавери-то помочь мне?
07:40
zi_rus: сейчас на ребут и запуск - только запись аудита
07:41
Все радуйтесь! У нас появился "Solution!", но какое у него API - это секрет, как им управлять неизвестно, и чтобы там что-то изменить, нужно быть разработчиком на Python. Т.е. 99% пользователей - в пролете
07:47
с пирулями кстати было точно также
07:47
прямо один в один
07:47
только их еще и отлаживать было напрочь невозможно
07:47
Dmitry1: lib/solutions.py
07:48
а тут ремоут дебаг врубил и погнали
07:48
вот тебе весь его API
07:48
dvolodin, Dmitry1 прав. нужна дока.
07:48
а тут тебе и mercurial в полный рост, и дебаг, и notebook
07:48
и переписывание ключевых моментов вроде раскраски порта
07:48
я вот какое-то время думал, что про пирули уже понимаю, но вот как код можно прикрутить к событиям изменения конфига? отдается ли эта разница или как-то ее нужно самому вычисялять? куча вопросов
07:48
и модульная структура
07:49
TSergey: костылем -- через event trigger
07:49
евент триггер - костыль ?
07:49
Дима говорит, что костыль
07:49
в том-то и проблема, что я я не понимаю как это, примера нет, описалова нет
07:50
freeseacher: смотря для чего
07:50
если разово подпереть какую-то железку -- нормальный механизм
07:50
07:50
дима вот нормальный пример
07:50
если какой-то принципиальный функционал -- то лучше в solution
07:50
подозреваю что по новому будет вовсе не так
07:51
да, короче в 50 раз
07:51
вот на тех же сущностях там же в статье напиши а ?:
07:51
просто сказать ему, что на этот класс события нужно ребутиться
07:51
freeseacher: я начал ровно на той статье писать
07:51
с чего я reboot с утра закоммитил ;)
07:51
в МО можно указать пирули для Rules --- в них чего-то передается? или это только точка входа?
07:51
freesearcher: if not event.managed_object.is_managed: return # Create MRT t = ReduceTask.create_task(event.managed_object.name,"pyrule:mrt_result","","commands",{"commands": ["reboot"]}, TO) t.get_result() return
07:52
Где мне такой травы взять?
07:52
ты чо :)
07:52
просто же совсекм
07:52
Я про это: t = ReduceTask.create_task(event.managed_object.name,"pyrule:mrt_result","","commands",{"commands": ["reboot"]}, TO)
07:52
event.managed_object.scripts.commands(commands=["reboot"])
07:52
У нас сейчас на канале 38 пользователей
07:52
или event.managed_object.scripts.reboot()
07:52
:)
07:53
Давай спросим их, кто из них понял, что эта строчка выполняет?
07:53
я вообще ни хрена уже не понимаю что тут происходит
07:53
dvolodin отвлеку немного от бурного обсуждения :) недавние коммиты про алармы поломали закрыти этих самых алармов
07:54
dvolodin, ты предлагаешь настраивать нок методом написания кода?
07:54
я примерно с появления каки-то сервисов
07:54
да
07:54
это он и предлагает
07:54
lexus-omsk: давай делали
07:54
zi_rus: когда функционал не может быть описан конфигом, то да -- кодом
07:54
сейчас поищу трейсы, пока вижу в вебке Failed to close alarm
07:55
в МО можно указать пирули для Rules --- в них чего-то передается? или это только точка входа?
07:55
dvolodin: Ты сам себе противоречишь. 90% FM описывается в JSON
07:56
так же как и 90% inventory
07:57
Dmitry1: handlers в JSON тебя не смущает?
07:57
TSergey: Тссс.. Это секрет. Никто кроме dvolodin'а не знает, что передается в pytule и возвращается ими
07:57
и куча примеров event и alarm handlers которые уже лежат в NOC?
07:58
смущают
07:58
криво, до невозможности
07:58
предложи прямой вариант
07:58
алиасы
07:58
документированные
07:59
dvolodin кажись разобрался, создал конфиг класса на незакрывающийся аларм и всё закрылось... может дефолты забить какие-нибудь на все классы?
07:59
а меня вот это сильно :)
07:59
07:59
не понимаю почему нельзя допилить механизм
07:59
а то как-то не радует конфигурить все возможные классы вручную
08:01
dvolodin: Дим.
08:01
1. Перенеси все в ивенттиггеры. (ими можно управлять)
08:01
2. Сделай алиасы для всяких "noc.fm.handlers.event.audit.log_started" (например log_started)
08:01
3. Написание этих триггеров должно быть доступно человеку, в первый раз увидевшему NOC и python
08:04
TSergey pyrule в MO - это для проверки (валидации) и ещё кое-какой обработки конфигов, соотвественно передаётся туда конфиг
08:05
описания всех интерфейсов (что куда передаётся и возвращается есть в ./sa/interfaces/)
08:06
Я, честно, говоря только что увидел эти handlers
08:06
lexus-omsk: как передается-то? все равно нужно самому сравнить текущий и предыдущий?
08:06
И нифига не понял. Например, чем "noc.fm.handlers.event.audit.log_reboot" будет отличеться от "n.f.h.et.a.l" ?
08:07
форум бы, там иногда и dvolodin куски кодов выкладывал
08:09
Я уже Диме тысячу раз говорил, что пусть не пытается все писать сам. Есть куча народу. Всего-навсего нужно предоставить простое API, которое будет стопроцентно покрывать все нужды
08:09
дима, вот вам api для event и alarm handler'ов
08:09
простое как валенок
08:10
event trigger-ы -- локальная модификация
08:11
тогда тебе вопрос -- что ты считаешь API?
08:11
:)
08:12
вызов одиночных функций типа "сделать зашибись"
08:13
system.os.shell("rm -rf /")
08:13
print "Complete!"
08:13
вот смотри пример: interface.py из solution
08:13
строке
08:13
строка
08:13
elif InterfaceClassificationRule.objects.filter(is_active=True).count():
08:14
Что такое InterfaceClassificationRule ?
08:14
Какие у него методы?
08:14
Какие у него переменные ?
08:14
дальше:
08:14
r = list(PyRule.objects.filter(name=p,
08:14
interface="IInterfaceClassification"))
08:15
list - понятно
08:15
дальше - нет
08:15
InterfaceClassificationRuleю__dict__
08:15
вместо ю точка
08:15
и увидишь что там есть(кроме методов)
08:16
dir(InterfaceClassificationRule)
08:16
м увидишь вообще все
08:17
_4ePTeHok: зайду издалека. Ты про ООП слышал? Про инкапсуляцию?
08:18
а ето сто по твоему?)
08:18
объект пируль
08:19
в классификации питона - класс
08:19
имеющий разные методы
08:19
"noc.fm.handlers.event.audit.log_reboot"
08:19
ты сейчас показываешь путь
08:20
потому что у питона структура импортов такая
08:21
повторюсь
08:21
Ты про ООП слышал? Про инкапсуляцию?
08:22
в общем ясно
08:22
я ничего не знаю про ООП
08:22
а нок сделан неверно
08:22
в языке который изначально подразумевает работу только по принципам ООП
08:22
ибо все что есть в питоне - это объекты
08:24
и что там не так
08:24
каждый скрипт - это класс
08:24
от родителя - интерфейса
08:38
TSergey: твои железки залинковались ?
08:40
нет, с чего бы
08:40
не было патчей
08:40
это трабл метода
08:41
TSergey: "local_interface": "1:20" а "remote_port": "1/25", плюс почему-то "remote_port_subtype": 7,
08:41
TSergey: я высылал вчера патч
08:42
он не помог
08:42
скрин я уже сделал после патча
08:42
имхо, у тебя с названиями интерфейсов лажа - поэтому не линкуется
08:42
Huko: ага, свежее предположение
08:43
dvolodin: да, его я и установил
08:43
Дим, у тебя крайне странная логика
08:43
точнее руками поменял код, т.к. то что было вчера командой не установилось
08:43
ты требуешь вызова простых функций при событиях и alarm'ах
08:44
Huko: посмотри скрин, плс
08:44
я тебе говорю, что это есть и уже используется
08:44
и есть куча примеров
08:44
Huko: ты видишьЮ что железки друг друга правильно видят?
08:44
теперь тебе не нравится, что функции указываются в виде noc.fm.handlers.event......
08:46
TSergey: я посмотрел, и на вывод скрипта посмотрел. в скрине у тебя remote порт 25, при том, что в скрипте он выдает как 1/25. попробуй жестко везде прописать "remote_port_subtype": 5
08:46
Huko: сэнкс
08:47
но скрин я сделал уже после патча, выложенного dvolodin
08:47
local(7) - convert to integer and return untouched, как 1/25 конвертнется в интегер ?
08:47
так вот, уверяю тебя, если ты возьмешь первый попавшийся JAVA продукт типа HP SA, ты будешь ровно точно также указывать java'вские методы ровно в таких же чудовищных модулях
08:47
а "1/25" уже поправлено ранее Dmytry1
08:47
и еще в довесок будешь воротить груду XML'ей для конфига
08:48
Huko: а тебя никак не смущат, что обе железки нашли друг друга как кандидаты? и видсят порты одинаково?
08:50
если метод их так показывает в вебе --- то значит дальнейшая проверка что-то делает не так
08:50
ведь "глазами" видно, что они нашли друг друга :)
08:50
TSergey: накати патч
08:50
TSergey: меня больше смущает, разница в названии портв между 1/25 и 25, хотя если это что-то уже руками добовляли - тогда хз
08:51
dvolodin: несмотря на то, что вчера его накатывал?
08:51
сейчас сделаю
08:51
TSergey: а ты его накатывал?
08:51
тогда проверяй get_interface_names для профиля
08:51
да, он накатился с ошибками
08:51
и я вставил кусок кода руками
08:51
оно на 1/25 должно выдать ["25"]
08:53
наделайте скриптов reboot
08:53
:)
08:53
я тут взбаламучу
08:53
но давайте уже статусы а :(
08:54
dvolodin: оно и выдает, я Dmytry1 спрашивал
08:54
"if name.startswith("1/") or name.startswith("1:"):" в интервейсах для DLink DxS
08:56
TSergey: твой get_lldp_neighbors s67-1-1.intt говорит обратное. или это уже устаревшая паста ?
08:56
а линк дискавери из get_lldp_neighbors инфу берет?
08:57
если метод дискавери lldp то похоже, что да
08:59
root@noc:/opt/noc# hg import -f --no-commit /home/tsergey/lldp.txt
08:59
applying /home/tsergey/lldp.txt
08:59
patching file inv/discovery/jobs/link_discovery.py
08:59
Hunk #1 FAILED at 44
08:59
1 out of 1 hunks FAILED -- saving rejects to file inv/discovery/jobs/link_discovery.py.rej
08:59
abort: patch failed to apply
08:59
вот так говорит на патч
08:59
dvolodin, а почему нотебук может не работать?
08:59
File "/usr/local/noc/main/management/commands/notebook.py", line 24, in handle
08:59
from IPython.frontend.html.notebook import notebookapp
08:59
ImportError: No module named IPython.frontend.html.notebook
08:59
там что то отдельно ставить надо?
09:00
TSergey: похоже, что в get_lldp_neighbors надо добавить вызов convert_interface_name
09:01
так даже вроде патч на эту тему был
09:01
ща
09:04
09:07
TSergey: что сейчас показывает get_lldp_neighbors на железке s67-1-1 и на порту 1:20 ?
09:08
IReboot вообще звучит
09:08
почти эппл
09:09
Huko: секунд, ща еще раз передискаверю
09:12
_4ePTeHok: ./bin/pip install ipython
09:20
вот блин. теперь оно требует pyzmq, а на его сборке валится)
09:20
какое капризное
09:22
Huko: вот свежак
09:22
09:23
там еще в скрипте dlink'а нужно сделать, чтобы он не пытался нормализовывать имена
09:25
Pending link check: s448-1-1.intt:25 -> s67-1-1.intt:1:20
09:25
Scheduling check for s448-1-1.intt:25 -> s67-1-1.intt:20
09:25
ну вот же, шедулинг засылает уже не то имя, что видит пендинг
09:28
TSergey: тоже самое - "remote_port": "1/25", при том, что гет_интерфейс это порт называется просто 25. имхо, надо на уровне get_lldp_neighbors делать нормализацию имен, а то какая-то каша получается
09:29
Huko: я согласен с тобой
09:29
но ты видишь, что дволодин находит порты? что засылает их в проверку?
09:30
"get_neighbor(00:21:91:8D:2D:8F, 4) -> s448-1-1.intt
09:30
Link candidate found: 1:20 -> s448-1-1.intt:25"
09:31
дальше-то нам зачем get_lldp_neighbors? ведь он взял кандидата из сосоедей, зашедулил его проверку
09:31
зачем в этой проверке еще lldp?
09:31
*соседей
09:33
сегодня, кстати, неапрувленных линков и вовсе не показывает
09:33
TSergey: а как он по твоему линки строит ?
09:34
по моему --- по lldp смотрит соседей, потом у кандидата ищет соседей по lldp
09:34
потом сверяет :)
09:36
вот тут, ты видишь что-то неправильное?
09:36
s448-1-1.intt:
09:36
get_neighbor(D8:FE:E3:8D:4A:20, 4) -> s67-1-1.intt
09:36
Link candidate found: 25 -> s67-1-1.intt:20
09:36
Pending link check: s448-1-1.intt:25 -> s67-1-1.intt:1:20
09:36
Scheduling check for s448-1-1.intt:25 -> s67-1-1.intt:20
09:36
s67-1-1.intt:
09:36
get_neighbor(00:21:91:8D:2D:8F, 4) -> s448-1-1.intt
09:36
Link candidate found: 1:20 -> s448-1-1.intt:25
09:36
Pending link check: s67-1-1.intt:20 -> s448-1-1.intt:25
09:36
Scheduling check for s67-1-1.intt:1:20 -> s448-1-1.intt:25
09:37
или этот лог кривой, или он берет порты не так, как пишет в лог
09:37
TSergey: я смутно представляю, что делает link_discovery.py но без правильной выдачи get_lldp_neighbors с приавильными названиями интерфейсов, никаие линки не построятся
09:41
Dmitry1, только что удалось протестировать сообщения в фм o dying-gasp, получилось кошерно, претензий нет
09:41
_4ePTeHok: ты еще сдесь?
09:42
Dmitry1: скажи чего-нибудь, плс
09:42
хорошего
09:42
ничего хорошего
09:44
_4ePTeHok: Про разработку профилей SA
09:44
смотри пример скрипта
09:45
s = self.cli("show switch", cached=True)
09:45
а у тебя выходит, что надо писать
09:45
s = noc.sa.bla-bla.foo-foo.ololo.egegey.cli("show switch", cached=True)
09:46
хм, есть коммит на lldp_discovery, четыре часа назад
09:46
изумительно
09:49
Dmitry1, ты придираешься, какой профит от длины слов?
09:49
такой, что разработчикам профилей SA не нужно знать эти noc.sa.bla-bla.foo-foo.ololo.egegey, и что там находится
09:50
все интерфейсы сведены в NOCScript
09:51
принципиально это все равно ничего не меняет
09:52
не надо знать одно, надо знать другое
09:52
порог входа для разработчика ниже же
09:53
Соответственно усложнение API отпугивает кучу разработчиков
09:54
вот пример описания функции из класса Script
09:55
def expand_rangelist(self, s):
09:55
"""
09:55
Expand expressions like "1,2,5-7" to [1, 2, 5, 6, 7]
09:55
"""
09:55
все ясно и понятно
09:57
Dmitry1: научи, чего сделать, чтобы мои коммутаторы слинковались? ты нормализацию сделал, dvolodin поправил дискавери, get_lldp_neighbors по прежнему показывает "remote_port": "1/25"
09:58
чего нужно еще собрать, что бы вы могли поправить?
09:58
эххх
09:58
собрать комессию медиумов
10:00
zi_rus: а ты не знаешь, что у многих не линкуется? хотя даже глазами видно, что соседи найдены?
10:00
имена портов уже говорили как я понимаю
10:01
Dmitry1: а ты можешь поправить вывод имени в get_lldp_neighbors? что-бы вот эта отмазка кончилась?
10:02
это по lldp отдает сама железяка
10:05
Dmitry1: и ты не нормализуешь к имени порта?
10:05
есть же у тебя функция
10:06
10:06
а вот тут пример без слэша
10:06
по 24 портам
10:07
1:24 и 24
10:07
не то
10:07
у нас есть функция get_interface_names()
10:08
которая возвращает возможные написания портов
10:08
просто в самом дискавери ее не срвсем корректно используют
10:10
в noc / inv / discovery / jobs / link_discovery.py
10:10
и вовсе не используют
10:11
вру
10:13
а нет, не вру
10:18
Dmitry1: т.е. нужно просить dvolodin в link_discovery.py взять порты так, как в lldp_discovery.py?
10:18
или все сложнее?
10:34
Config diff filter pyrule как работает? мне его надо использовать если я хочу чтобы не было писем об изменениях в строках конфига которые начинаются на !
10:56
zi_rus, никак.
10:56
хотя быть может теперь уже и работают
10:57
на вход подаются строки после дифа
10:57
у меня в меркуриаловской реализации полностью избавиться от письма не удавалась
10:57
строки в списке или весь дифф куском
10:57
быть может сейчас при слегка изменившемся формате будет лучше
10:57
куском
10:58
str diff
10:58
мне часто валились письма по изменениям в шапке конфига, кто последним его менял
10:58
это выкусывать нужно
10:58
я сделал в скрипте get_config срезание не 3х строк а 7
10:58
прямо в задании get_config
10:59
мне кажется через diff filter будет правильней
11:00
или закоммитте новый вариант или скажите что я лох и дифф фильтер кошерней
11:03
--- a/sa/profiles/Cisco/IOS/get_config.py Mon May 05 09:46:58 2014 +0400
11:03
+++ b/sa/profiles/Cisco/IOS/get_config.py Thu May 08 15:04:35 2014 +0400
11:03
@@ -17,5 +17,5 @@
11:03
11:03
def execute(self):
11:03
config = self.cli("show running-config")
11:03
- config = self.strip_first_lines(config, 3)
11:03
+ config = self.strip_first_lines(config, 7)
11:03
return self.cleaned_config(config)
11:17
фейл такого подхода вот в чем
11:17
у железки после ребута 7 строк выглядят по-другому
11:17
Building configuration...
11:17
Current configuration : 36952 bytes
11:17
!
11:17
! No configuration change since last restart
11:17
!
11:17
version 12.2
11:18
захватывается version 12.2
11:19
если появляются изменения то не захватывается потому что за ! становится на одну строчку больше
11:19
как вариант, прямо в get_config выпиливать все строки которые начинаются с !
16:25
16:25
вот
16:26
простейший пример, как можно применить event handler для конкретной задачи
16:32
dvolodin, так и не понял чем отличается новый метод от старого, раньше триггер реагировал на ивент и запускал пируль, теперь тоже самое только вызывается хендлер
16:32
и ради чего все это?
16:42
тем, что есть определенный набор handler'ов из коробки
16:43
и опять же -- можно собирать solution'ы со своей логикой работы
16:43
нормально тестировать и переносить между системами
16:47
вот представь, ты научился автоматом проводить какие-то восстановительные работы по event'ам
16:47
собрал пачку скриптов, навесил обрабочики, получился нормальный полезный продукт
16:48
выложил свой solution, кому надо - поставят
16:48
ровно одной строчкой в конфиге
16:48
пирули тоже можно из коробки накидать, тот же триггер на config changed
16:50
в пирулях также свою логику можно реализовать
16:50
ну вот никакой разницы
16:50
есть триггер, реакция на ивент определенного класса, есть действие в пируле или хендлере
16:52
ну
16:52
и что тебя смущает?
16:52
шило на мыло
16:52
профита ровно ноль
16:53
зачем это вообще было реализовывать?
16:57
тестирование и перенос между инсталляциями
Share this page
Share this page: