nocproject.org

.

ну так что с привязкой валидаторов решим?

..

отвязные валидаторы?

партихард валидаторы

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

https://pp.vk.me/c625528/v625528151/24263/CwWBNCats0U.jpg

https://pp.vk.me/c625528/v625528151/2428b/qRW8h2HyF-A.jpg

https://pp.vk.me/c625528/v625528151/24281/Lq2GzfzMh1M.jpg

хороший подарок любимому вендору

ты добрый

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

zi_rus: я в курсе

самый противоречивый момент во всем

мы такой момент рассматривали

есть обычный коммутатор доступа, но к нему подключен какой-то vip

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

именно на уровне коммутатора

и к нему же подключен юрик

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

да, у нас была похожая ситуация

есть юрики со своими настройками, а есть базовые станции со своими

я в пируле разделил их по дескрипшену

во, да, коммутаторы под БС -- тоже отдельный прикол

на самом деле коммутаторы вещь универсальная

вопрос только в портах

++

dvolodin: это приводит нас к профилям интерфейсов

zi_rus: возможно

и как следствие, глобальные настройки по МО логично привязывать к профилю МО

а это значит в жопу роли и плясать от профилей

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

zi_rus: не совсем так

смотри

zi_rus: ++

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

то, что ты предлагаешь, означает примерно следующее

нужно иметь возможность навеить на МО несколько профилей?

*навесить

нет

нахер

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

ну это детали

ну нифига себе детали

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

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

если у тебя уникальные железки на которых специфические настройки

по твоей логике его следует снести в object profile

то в общем случае там нечего профилировать или валидировать

каждый раз настройки или есть или ничего не работает

dvolodin: да, уже второй день это талдычу

я бы и auth profile в обжект профиль засунул, но вы сопротивляетесь

а вот если есть профили "access", "iptv", "aggregation", "vip" и можно их нафигачить на один МО, то все логичнее

чтобы при добавлении МО указать имя, ip, СА профиль и обжект профиль

я сейчас такое с помошью тэгов разруливаю

TSergey: а что тебе еще надо

TSergey: то, что ты говоришь - обозвали роли

какая разница, теги это будут или роли

zi_rus: ну считай, что роли -- это структурированные теги

freeseacher говорил о привязке к ролям параметров.

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

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

zi_rus: там вторым шагом freeseacher хотел role discovery :)

блять

хуй там отдискаверишь

все будет зависеть от дизайна сети

dvolodin: так и ко всем профилям, ролям, доменам и пр --- это же характеристика МО, может это все должно быть "структурированным тэгом" и добавлятся к МО по необходимости

вот смотри

для чего весь сыр бор

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

проверки -- классы такого вот вида

у них есть метод is_applicable

который говорит, можно ли или нельзя применять проверку

то есть задача такая

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

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

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

ну а дальше валидируем

хех, блэклист инкаминг

эммм

зачем первый шаг

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

dvolodin: таки еще раз

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

без деталей реализации

ну или общеми словами если проблема именно в реализации

я тут

*общими

ща почитаю чего вы там с утра пописали

и все вам раскаажу :)

почитал :) немного вы и пописали

роль порта это тоже нужная вещь.

идя внедрить еще одну надсущность для МО

*идея

нет

идея в невнедрять лишних сущностей

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

э, ну Дима именно про надсущность говорит

и я тоже говорю про надсущность

и вариант с "сервисными тегами" меня тодже устраивает

в том случае если их никто не может меняь

это будет тоже самое что я хочу

может есть смысл поговорить о том как иметь в МО несколько надсущностей и все их называть профилем МО?

эээ

эээ

ну и чего :)

TSergey: профиль - это как в cli получить конфиг. всё. как распарсить этот конфиг

профиль существующий у нас сейчас?

но одна и таже железяка может быть брасом и либо иметь на себе нат либо не иметь.

да тот который у нас

настройка дискавери у нас тоже на нем

а это, кстати, аплодисменты авторам

zi_rus: грубо говоря, на выходе я хочу получить эти самые error

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

evyscr: они все законные. :)

и шо?

и названия у них правильные

в терминологии будут путаться тыщу лет

да пофиг. сейчас эт не вопрос

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

и как хранить настройки валидаторов

ну и добавим "роль", и у роли есть тип, а ролей можно к МО много :)

роль "профиль_железа", роль "домен", роль "важность железки"

в каждой роли, по типу, разные настройки и обработки

тогда "простая" железка будет иметь пару-тройку ролей: "дисквери", "доступ", "dlink"

сложная --- букет

понадобится еще одна сущность --- мехенизм добавления к МО есть, не плодятся конкретизирующие поля

TSergey: у роли нет типа. только название и характеристики

да хоть как, я к тому, что сейчас еще одну сущность нужно добавить в МО

хотя твоя идея мне импонирует.

а нужно иметь механизм навешивания таких штук на МО

freeee: а, гут :)

cap_discovery это оно

механизм навешивания ролей

freeee: ну не нужно это все

и для порта должен быть аналог такой :)

хорошо zi_rus жги

как надо

freeee: ты же сказал что прочитал все что мы написали

и не увидел конкретных предложений

zi_rus: вот тебе простой кейс.

есть железяка jiniper.junos

ее надо отвалидировать

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

согласно профилю

какому ?

обжект

там где мы методы дискавери указываем

тоесть Juniper.JuNOS

и прочее

нет

не са, а обжект

mo profile

я ж говорил про авторов-)

хорошо.

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

а в какой mo profile ты его посадил?

в опрашивать: конфиг, пинговать раз в 5 минут, не запрашивать lldp, запрашивать инвентарную инфу

в этот

freeee: если у тебя 1000 джуниперов с бгп, то правильный профиль - "опрашивать: конфиг, пинговать раз в 5 минут, не запрашивать lldp, запрашивать инвентарную инфу" + проверять настройки бгп

а что в этом mo profile сказано про bgp?

здрасте

rё

zi_rus: откуда я знаю что надо проверять в нем bgp ?

вообще, тема extending mo profile весьма благодатна

а откуда ты знаешь что там вообще джунипер

так в ноке записано жи

а откуда ты знаешь что там вообще есть этот мо

из того что я задал у него profile_name

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

как-то можно всех сирот пристроить?

misak: барев дзес?

:)

ой

freeee: ты пользовался здравым смыслом когда выбирал профиль7

misak: ну таки в монге попробуй db.noc.objects.find()

или хернул первый попавшийся

misak: там в принципе понятные поля

я их нахожу, а дальше что делать?

drop()

гугли mongo update :)

??

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

поменять папу?

типа да

мля :(

боюсь я

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

нельзя всех сирот кинуть в ЛФ?

в ней написано что для устройства с название bgw и профмлем junos мне надо поставить тот самый валидатор

ну вот

для жуниперов с бгв один профиль, а без - другой

логично? просто?

прозрачно?

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

misak: можно

проставив им поле container

freeee: когда название изменится, тогда и сменишь

zi_rus: один недостаток - профилей расплодится до хрена

ок, попробую

название чего ?

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

у железяки есть жизненный цикл. и есть внедренные на ней фичи

evyscr: и второй --- в них будет очень большой процент дубляжа

сегодня на ней нет bgp завтра есть

сегодня на ней нету ната а завтра он появился

при добавлении фич на железяку я должен зайти в нок и изменить профиль мо?

таки да

хуй.

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

ну блин

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

freeee: нет

как нет то

у меня фич навернуто на коробку полсотни или больше

да вот так

и что?

железяк под две сотни

ты их раз в неделю перетряхиваешь?\

да

ну вот и подумай над этим

цикл внедрения одной фичи полгода

сеть настроена и работает

zi_rus: сколько штук у тебя использовалось профилей?

к моменту когда я внедрил одну яичу везде я на половине уже внедрил две другие

freeee: у тебя вообще должны быть ещё проекты

что проекты ?

что приборы?

в ноке есть такая хрень

нах они мне ?

лёль

а нах нормальным людям перетряхивать раз в неделю?

TSergey: было с десяток, и только потому что некоторые профили пришлось разбить, есть у меня РЕ, для них один профиль, но на парочке включен CDP, пришлось им отдельный нарисовать, чтобы дискавери работал

zi_rus: это говорит о том, что у тебя одностипное оборудование и однотипный набор опций на нем

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

*однотипное

оно у всех однотипное

неа

сети уже 15 лет так строят

хихик

нефига

есть доступ, есть агрегация, есть ядро

хихик(2)

++

да, и есть некоторое пересечение функций

есть

и оборудования

zi_rus: короче это не вариант.

слился да?

фичи на коробке надо дискаверить

нихуя

да уж

надо что бы нок сам узнал что тут есть bgp

и проверил его

сам валидатор и может

если фича есть, она должна быть настроена корректно

нормальность нерабочести фичи - административное

открывает конфиг

валидатор не знает применим ли он

видит bgp

у меня стоит на доступе des-2108 и когда-то его заменят на des-3200, а профиль мне нужно указать без кучи дискавери, чтоб 2108 не снашали запросами

записал в факты, на железке есть bgp

и хули?

конфиг открывает не валидатор

валидатор вообще с конфигом не работает

да похер на терминологию

он работает с базой вактов

не похер. здесь важно

важно что нок может увидеть из конфига

вот только

это бгп железка

или наоборот

парсер вытащил информацию о том что тут есть bgp но он так же вытащил настройки этого bgp

и у нас есть факт

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

нок никогда не узнает

который называется bgp timeout

он установлен в 180 сек.

это правильная цифра ?

freeee: нок отдискаверил что на железке включен бгп и применил валидатор бгп - это правильно или бгп вообще надо отключить?

ответь сначала на мой вопрос

кроме тебя никто не знает что должно работать на железке и с какими настройками

freeee: мой вопрос автоматически отменяет твой

я знаю что цифра 180 может разниться от внедренных фич и роли железяки.

не отменяет, вообще-то

хах

а может зависеть от пира

и может зависить от пира

да

и похер на внедрённые фичи

не похер.

evyscr: просто придется сделать пир профиль и засунуть в peering management Ж)

ты изменяешь набор фич, а таймаут определяется пиром

zi_rus: ну я не знаю...

zi_rus: дело в том что ты не принимаешь в расчет то что валидатор bgp должен получить какой то конфиг себя

freeee: а давай я скажу, что должно быть две конфигурации сети - плановая и фактическая

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

:))))) "конфигурация сети"

да

evyscr: ты в банке что ли работаешь ?

нет

у тебя два дифа в месяц ?

больше

и что?

о боже мой. четыре ?

бля, иди нахуй.

ПЯТЬ! ?

ребят

вот представьте, что у вас 50k железок

смысл в том что сеть живет сама. в нее разные люди в разных городах примерно 100 человек вписывают настройки

https://pp.vk.me/c623429/v623429186/21f18/84E5VTD3u0g.jpg

freeee: +++

e_zombie: зачет

мы не знаем когда и кто добавил или изменил что либо

фотка к сожалению не моя. но эту тёлочку 21 числа буду фоткать. возможно даже с вагиной

но в этом хаусе нам надо валидировать хорошо ли они это сделали

они должны открыть рекомендации по внедрению фич и накотить их

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

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

долбоёб включил и настроил по шаблону bgp там, где не надо. пришёл нок и сказал: всё заебись

seems legit

evyscr: bgp настроен верно ?

ну-ка, раскрой термин "верно"

проходит валидацию

лехко

в ноке регулярно работает не то, что надо

значит полдела уже сделано.

и не работает то, что надо

то что надо вадидировать совместимость ролей это уже отдельный вопрос

полдела, лёль

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

кому очевидно?

согласен. не очевидно.

просто более вероятно.

it depends

в конечном счете на железяке будет несколько ролей или "сервисных тегов" или еще чего то там

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

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

раскрывай "ожидаемое"

валидатор пришел и увидел так это железяка претендует на то что она делает нат

значит у нее должно быть включены следующие alg

а то оно у тебя на фактическое больше похоже

таймауты расписаны вот так

а наты, как известно, разные бывают

в роли мы описали то как должно быть

и роль автодискаверится??

да

ну красота :)

не взлетит

роль это набор включенных фич

я хочу такой нок и такой как у dvlolodin, в котором все работает :)

"в роли мы описали то как должно быть"

"автодискаверится"

/0

хм.

можно пример ?

TSergey: изи, просто никогда не проверяй работу

freeee: ты сам задал вопрос про таймаут

возьмите как пример что-то попроще --- LLDP

он правильный или нет?

типа он включен, проверяем --- должен ли

капабилити пришел на коробку и сделал sh ip bgp

увидел что есть пиры

TSergey: как это проверить?-)

добавил в роли bgp

а если пир в дауне?

парсер пришел за конфигом

evyscr: валидацией конфига же, или нет?

увиедл тут два пира

настройки вот такие

TSergey: это административное решение

сделал из этого факты

с учетом дефолтов

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

валидатор пришел смотреть на факты

"8[15:52] evyscr: и роль автодискаверится??"

а это делается валидацией валидатора, по роли валидируемого валидатора

проверил факты. говорит bgp настроен верно

пришел валидатор ролей

о, вот он и пришел, валидатор ролей :)

и говорит эта железяка является l2 свитчом. а еще она bgp

это не порядок

и в итоге мы получили ошибку. на l2 свитче настроен bgp

dj всей концепции которая есть у меня в голове именно это звено самое слабое.

я предлагаю над ним подумать

как узнать на самом деле что на с3650 не стоит настраивать bgp

где-то долдно быть правило, по которому она в какой-то группе, на которой не должен быть bgp (профиль, роль, etc)

*должно

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

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

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

zi_rus: йопт :)

так, я вернулся с обеда

freeee: ты обкурился

ок. расказывай как надо

ты не знаешь какие роли должны быть на железке но предлагаешь их дискаверить

я не знаю какие должны быть роли да

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

но тем неменее я делаю и развиваю скрипты get_caps

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

что значит я тасую роли между железяками ?

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

все

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

хорошо. давай уйдем от слова роли

роли распределены

начинается настройка

и придем к слову сервисы

сервисы тоже ограничены

и определяются на этапе дизайна

но маркетинг хочет новые сервисы

по десять новых сервисов в месяц?

нет такого

по 12-17 в год.

на маленькой сети можно поизъебываться, но там нет проблемы

а на большой это многоэтапный процесс

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

по моему (очень скромному пока) --- нет, железка сначала может быть доступом, затем на нее включить юрика, а затем и вовсе пустить транзитом трафик на другой узел

и участие нока только в самом конце, на этапе реализации

TSergey: и при этом она останется доступом

именно так

остается

но настройки на ней изменятся трижды

но валидировать ее надо уже по другому

с соответсвующим профилем и валидатором

да ни хера

именно трижды и изменятся настройки

включеноие толстого брика может привести к тому что на ее порту появится qiniq настройки

так

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

кто-то сказал слово сервисы

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

нееееет

freeee: это отсутствие дизайна сети, если включение одного клиента ведет к тотальному реконфигу

dvolodin: только не это

поздно

ты не должен был прочитать именно эту строку

Ж)

забудь

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

одну

:)

бля.. :((

плюнь бяку?

dvolodin: не смей

теперь все рухнуло

zi_rus: на свитче дотсупа не должно быть qiniq это нормально

но клиент вязл и купил.

валидация как примочка к ordering? :)

железяку тотально переконфигурили

6 строк новых.

freeee: это уже обсуждали. валидатор в профиле интерфейсов

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

которая отдает данные в vip мониторинг

не выдумывай хуйни

эм...

и тем неменее

даже циска не делает отправку трапов на особые сервера пер-порт

есть единый мониторинг

в идеале сам нок

и все

зирус ты не разу не сталкивался с действительно большими юриками.

у нас под некоторых таких спец отдел поддержки создали

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

еще раз ОТДЕЛ ПОДДЕРЖКИ

ВЫДЕЛЕННЫЙ

БЛЯТЬ, БЛЯТЬ, БЛЯТЬ

у них все своё.

им им нахуй не нужны все свитчи.

только несколько сотен по всем городам

у нас такие называются "федеральные клиенты"

феодальные клиенты

dvolodin: у нас тоже. но прецедент уже создан.

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

ну и чего

ну есть

сейчас то с ними ты что делаешь

тотальный реконфиг железяки.

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

и ты считаешь что это нормально

я не считаю что это нормально

что все должны делать также

но это требование бизнеса

у тебя есть пирули ;)

валидация и пирули не связанные вещи

ты сам из нока все что угодно можешь сделать

связанная

чтобы не реконфигурить железки

есть точка входа

и она разруливает твои бизнес-заебы\

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

эм.

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

несколько сотен свитчей из более чем 200к

пришла авария по порту такого клиента - форварднул на спец отдел

делается скриптом

каким скриптом ?

их поделючает какой то инженер в городе

он подключил и все. забыл.

один раз придумать и потом похер хоть 100500 из 500к свичей таких

я как об этом должен узнать ?

как-то узнаешь для перенастройки свича

zi_rus: не задумывался, что ты советуешь как что-то делать, не имея опыта конкретной ситуации? ну типа мы просто другие пользователи нока, с другим набором оборудования, с другим набором бизнес-задач?

это сделал другой инженер в тп или в городе

TSergey: не важно какой есть опыт, важно наличие здравого смысла

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

zi_rus: ну так-то да, или ты ошибаешься про опыт и переоцениваешь здравость :)

zi_rus: ладно я понял. ты просто еще не сталкивался с такими задачами.

TSergey: есть херова туча контор, все работают по-разному, но домен у них на винде и работает он по майкрософтовским правилам

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

как и любой другой спец

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

TSergey: я признаю логичные аргументы, я таких не услышал, почему надо делать так, а не иначе. тут сидит сорок человек, но так как рассказывает freeee нужно только ему

zi_rus: я как раз не пытаюсь вшивать никакую жетскую логику

даже dvolodin такого не преложил, а уж от него я тоже наслушался норкомании

она вся мягкая и поддатливая

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

просто я решаю вопрос исходя из действительного опыта того как это работает

*никогда

TSergey: если оно нереализуемо, значит здравого там чуть меньше чем ничего

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

у меня тоже есть свои, кривенькие

и я имею опыт эксплуатации их

а еще у тебя сеть которая не имеет дизайна

эм. странный вывод.

вполне логичный

zi_rus: а ты неприятная личность :)

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

некоторые сервисы появляются а некоторые исчезают

при чем тут дизайн ?

модель предоставления сервисов - часть дизайна сети

TSergey: то есть и у тебя аргументы закончились, но почему-то виноватым считают меня

мне не нравится твой тон, а аргументы я понимаю и твои и freee

zi_rus: почему вдруг новые сервисы то не появляются я понять не могу ?

TSergey: ты видишь буквы, а не интонацию

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

zi_rus: сделай одолжение, скажи что таоке дизайн сети, в рамках вот твоей фразы?

*такое

это новый сервис

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

цикл внедрения пару месяцев.

где то уже внедрили

где то у яндекса прописать 3 сетки в acl

где то четыре

спустя полгода у яндекса появился еще одна подсеть

какие 100 мбит до яндекса?

л3 впн?

л2 канал?

интернет

пиринг

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

новоле направление

*новое

так вот спустя полгода я просто в найстройках валидатора скажу что есть 5 сетей

или даже лучше просто поставлю сети яндекса в ipam отметку о том что она должна быть в этой acl

и на всех железяках валидатор проверит этот acl

зачем тебе сети яндекса в твоем ипаме?

потому что все сети использованные в конфигах должны быть описаны в ipam

ну и все

в валидаторе для браса вставляешь эти строчки

или ты по приходу менеджера ASBR под брас перестраиваешь?

а при чем тут брас ?

он только ~20% мест где указаны эти сети

сколько у нас длинна строки максимальная для атребута объекта МО ?

TSergey: дизайн это сложный термин, определяет как должна строиться сеть, от общих принципов, до конкретных настроек, в том числе там определяется модель предоставления различных сервисов

да блин. новые сервисы то чо ?

это не новый сервис

3 года назад мы разобрали трафиковый доступ в интренет

это модификация существующего

все он стал ненужен

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

zi_rus: и говоря что отсутствует дизайн сети, ты имеешь ввиду, что вся сложность не реализована

нет, я говорю что настройки на оборудовании не соответствуют единому подходу

при эксплуатации такой сети будут постоянные проблемы

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

либо каждый раз это придется перепроверять

дык да.

что катастрафически увеличивает сложность обслуживания

вот пусть вадидатор и провряет

он для этого и нужен

валидатор должен быть настроен по шаблону

шаблон определен дизайном

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

роли железок также определяются дизайном

чо ?

то

асбр это асбр а не брас

Илья, ты - перфекционист.

да

дык вот бизнес к перфекционизму отношения не имеет.

перфекционизм это к религии больше.

бизнес нет, а технические решения могут

и даже должны

ты определил проблему

и пытаешься ее решить

валидаторы позволяют автоматизировать ручную работу

и подойти к идеалу

когда обычные люди лажают

ладно. в пездцу. давай конкретику.

где должден быть задан параметр bgp таймаут ?

в валидаторе

ваилдатор привязан к профилю

как выглядит валидатор ?

профиль навешен на мо

как-то выглядит

как

if not (bgp_timeout==30) then: error

если клиент хочет другой таймаут ?

dvolodin: добавил бы удаление шасси для объекта у которого сняли "is_managed", вот сейчас тупил почему переставленный не линкуется

freeee: щзначит судьба

ты от меня чего хочешь?

хорошо давай проще.

мне вообще не надо эти таймауты валидировать

в настрйоках задан сислог сервер

как узнать праивльный ли он

и все ли ожидаемые сислог сервера заданы

тбе пример показать?

я делал это

нет мне не пример показать

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

это работает

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

lkz rf;ljq ;tktprb cdjq dfkblfnjh c erfpfyysvb ghfdbkmysvb flhtcfvb

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

что значит свой ?

у нас валидация же по профилю

то и значит

отдельный

профиль у меня мы уже определились какой

дял одних железок один профиль

для других-другой

вот давай без этого

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

у меня есть в астрахани брас

на нем 6 сислогов

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

а в профиле задаем обязательные и опциональные роли для профиля

freeee: и?

то есть если на свиче доступа выползет BGP -- то это уже ошибка

zi_rus: каие из них правильные как узнать ? где записаны правильные ?

dvolodin: согласен.

такой вариант позвлит мне задать все роли как опциональные

да

и отсечь заведомо неверные

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

например, ospf на свиче доступа

да и вообще L3 на нем

ну и кто должен знать какие у тебя правильные

то есть мы берем профиль

навешиваем на него набор валидаторов и конфигов

часть валидаторов требует ролей

берем железку

парсим конфиг

прогоняем правила и извлекаем результирующие роли

как коробочные, так и свои

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

хорошо. так годиться

у нас тогда есть роли, статикой

слишком абстрактно

они все определены и мы их все знаем

для них для всех есть настройки

меня единственное что смущает что мы валидацию делаем на основании конфига.

в капсах я хотел давать команду и смотреть на ответ.

валидация конфига на основании конфига, да это очень странно :)

да. вот этот момент и торозит.

tckb ;tktprf hf,jnftn yt gj rjyabue - djn 'nj ,eltn cnhfyyj

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

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

номер acl-я там или состояние сессии или еще чего то

dvolodin: приведи примеры ролей

ну смотри, в clips есть хороший предикат exists

кроме router bgp/ospf

для некоторых фич мне надо знато что есть правило номер 150 в ip filter

другое дело,что в таком случае получается вот такая петрушка

роли мы берем из коробки или определяем

там просто имя и описание, это обычная коллекция

но помимо этого в роли мы определяем правила матчинга

dvolodin: и что мы имеем на выходе. по-моему роли опять лишняя надсущность над валидатором

ты разделил процесс на два этапа, но это видимость

по сути делается тоже самое

zi_rus: мы имеем на выходе следующее

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

если не вводить роли, то придется эти условия повторять по всем валидаторам

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

zi_rus: парсер про роли ничего не знает

dvolodin: шта?

<dvolodin> текущий набор ролей мы выводим из результатов работы парсера

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

а1=1

а2=3

и тд

а в другом создаешь иерархию

фича АААА

а1=1

а2=3

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

то есть оптимизация какая-то полоучится

но я совершенно не уверен что в этом есть ощущаемые профит

насчет ощущаемого - не могу сказать

правила, да, могут упроститься

самое главное -- во всех правилах под L2 свичем будет пониматься одно и то же

и не будет разногласий

эмм

чую вероятные проблемы

ладно, делайте как хотите

я свое слово сказал

ну что

дали мне виртуалку

будем ставить нок

но зачем? (ТМ)

кровь кишки распидорасило (с)

анальный секас

копрофилия

палится твоя контора

вот вот прямо вижу как у вас там по углам

всякие непотребства творятся

hi

hello

хехе

it is possible to integrate in noc an automate generator for config?

something like netomata

zi_rus: а потом вы скажете, что NOC плох, в нем нет SS7

mpanait: django templates :)

ok

and snippets

and how i can use it?

dvolodin: пока что ипам, а там посмотрим как пойдет

look after Snippets

but in snippets (who use curently) is an push config

but for automate generation an config (from an minimal config) - just ip on interface, and configure from an scenario.....standard (build like snippets) or custom

mpanait: https://kb.nocproject.org/pages/viewpage.action?pageId=11567283

it is ok

thx

and has resolved problems

:)

"[17:45] <zi_rus> будем ставить нок" ггг.

нок почти так же аддиктивен как gpl

также что?

*адиттивен

а нет все таки я праивльно сначала написал

аддиктивен

pfcnfdbkb vtyz ueukbnm gjikst ckjdf

заставили меня гуглить пошлые слова

но схерали gpl, ежели бздя?

кстати, а кто-нибудь тыркал netcrunch? коммерческий который

freeee: ты тут?

+

freeee: чего ему не нравится на пустой инсталляции pastebin.com/JkKB1MdE

django.db.utils.IntegrityError: null value in column "description" violates not-null constraint

миграция не очень

freeee: я вижу, это апгрейд первый пытаюсь прогнать

сломать не мог еще ничего

мля

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

по кругу стал себя перезапускать

ну ты же не первый год в ноке

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

Т.е. нужно либо сниппет в шедулер засунуть, либо из пируля на железку залезать(что кажется не вариант)