dlink и juniper я упростил сильно

да может и киску так сделать

interface Gi0/1

description test

преобразовать в interface Gi0/1 description test

а давайте отрежем володину ногу? (с)

не надо, не надо, я вспомнил дорогу

клипс, да

вынести надо нафиг

тогда пушни мой коммит

и заменить обычным питоном

ну а фигли ты json в кучу со скриптом кинул?

оно само (с)

давайте подумаем, как удобнее писать валидаторы?

ну то что они в отдельных директориях как и профили это есть гуд.

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

это проще

там удобно - --debug ключик

для дискавери

2017-01-25 15:25:27,237 [scheduler.discovery] [12561] [discovery|box|BALT-AR1|id] Check is disabled. Skipping 2017-01-25 15:25:27,284 [scheduler.discovery] [12561] [discovery|box|BALT-AR1|config] Checking config 2017-01-25 15:25:27,285 [rpc.sae] [>CALL] get_credentials() 2017-01-25 15:25:27,286 [rpc.sae] [10.64.255.213:19022] Sending request 2017-01-25 15:25:27,302 [rpc.sae] [<CALL] get_credentials (16.43ms) 2017-01-25 15:25:27,302 [rpc.activator-default] [>CALL] script()

я бы не сказал

это циска

давайте подумаем, как удобнее писать валидаторы?

неееееееееееееееееееееееееееееееееет

да

:)

пиздетц

есть идеи?

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

к примеру ошибки по упавшим пингам и интерфейсам долетают, но ошибки с флапающим маком, но этой же делезке нет с другой упавший интерфейс - не прилетает

давайте подумаем, как удобнее писать валидаторы?

конфига?

да

@dvolodin Дмитрий, подскажите. SSID на точках забирать лучше в get_interfaces ?

:-/

не знаю

может отдельно все-таки?

хотя, с другой стороны

а не

точно не в интерфейсах

нормализация имени там обломается

ну вот

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

и куда его тогда корячить ?

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

в интерфейсы ?)

по логике вещей SSID в базу нужно сложить

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

метрики сейчас тоже делаются

Тааак

а что юудет, если я удалю нетфорк сегмент, в котором были железки?

они теперь трейсят в МО..

Это ожидаемое поведение?)

надо вернуть то что удалил)

я позавчера инветори разломал )

надо вернуть то что удалил)

не могу

=(

надо или бывший uuid сегмента восстановить или дропать МО

фиксы есть на эту тему?

давайте подумаем, как удобнее писать валидаторы?

имеешь в виду валидацию конфига с устройств? а с какой целью? показывать алармы?

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

через автоматизацию проверки конфигов на валидность.

EXCEPTION: <class 'noc.inv.models.networksegment.DoesNotExist'>

ГРУСТЬ!

Андрей, спасай!

ох какая это больная тема( мы как-то писали валидацию. в итоге делали это черезразбор текста конфига на вложенную структуру, и сами валидаторы были на питоне. в итоге проверки сводились к чему-то вроде: for ifname, iface in conf['interface']: if iface['mtu'] != '9000': ALARMA!!! ну или фикс прям тут

вот вот.

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

ERROR: S client not available

в итоге мы немного по другому пошли

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

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

было дуже забавно наблюдать результат.

кхм.

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

а не проще всё под одну гребёнку ?

в смысле?

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

во-первых он не может быть одинаковым, потому что везде разные версии железа и софта. + в разных локациях могут отличаться и модели железки. в одном регионе сети такая то фича включена - в другом нет. с этих данных и рендерится этот "одинаковый" конфиг. во-вторых не всегда изменения реально стоит выкатывать сразу. бывает факапочные ситуации, когда админ намерянно пошел и притушил svi например, а автоматика сразу придет и подними его обратно, еще и пизды отвалит админу)

@aversant тут?

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

такое будет работать, но не всегда

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

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

но тогда требуется сервисы вести

@aversant тут?

это правится в shell

естественно ничего не дается бесплатно

но подход вроде приживается

это правится в shell

будет время помочь?

UUID сегмента есть?

да, в трейсах видно

их было 2

там пара должна быть

Почитал про CLIPS, перепробовал кучу всего. Получилось, что пустое поле fact бывает по разному "пустым", согласно примеру из доки vlan_id обрабатывается и не вызывает ошибки. Но при попытке вписать именно input_ipv4_filter или pim_mode возникает ошибка синтаксиса.(о чём писал выше) Если скормить условие (input_ipv4_filter "188") - то отработает. ИТОГ(где нет acl): (defrule {{RULENAME}} (subinterface (input_ipv4_filter nil) (name ?n)) => (assert (error (type "Config | Match Template") (obj ?n))) ) не NULL, а именно nil ? ИТОГ(где есть acl): (defrule {{RULENAME}} (subinterface (admin_status 1) (name ?n)(input_ipv4_filter ?acl)) (not (subinterface (name ?n) (input_ipv4_filter nil))) => (assert (error (type "Config | Match Template") (obj ?n) (msg ?acl))) )

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

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

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

+++

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

ибо писать руками парсер не хочу

Почитал про CLIPS, перепробовал кучу всего. Получилось, что пустое поле fact бывает по разному "пустым", согласно примеру из доки vlan_id обрабатывается и не вызывает ошибки. Но при попытке вписать именно input_ipv4_filter или pim_mode возникает ошибка синтаксиса.(о чём писал выше) Если скормить условие (input_ipv4_filter "188") - то отработает. ИТОГ(где нет acl): (defrule {{RULENAME}} (subinterface (input_ipv4_filter nil) (name ?n)) => (assert (error (type "Config | Match Template") (obj ?n))) ) не NULL, а именно nil ? ИТОГ(где есть acl): (defrule {{RULENAME}} (subinterface (admin_status 1) (name ?n)(input_ipv4_filter ?acl)) (not (subinterface (name ?n) (input_ipv4_filter nil))) => (assert (error (type "Config | Match Template") (obj ?n) (msg ?acl))) )

E_zombie Можно этим дополнить документацию?(если надо, конечно)

да добавляй.

лишним не будет.