nocproject.org

как timeout скрипта увеличить?

после класса написать TIMEOUT = 120

и перезапустить нок

freeseacher: что-то я не понял stale discovery - там же все подряд устройства, даже те, где процесс discovery 15 минут назад прошёл

хм

ща

о спс :)

lexus-omsk, https://bitbucket.org/nocproject/noc/src/427439d0dfb8aa7d7dda8f676d3fe88122ab19d0/sa/apps/reportstalediscovery/views.py?at=default#cl-33

gte на lte поправь

о как... понял

помогло ?

помогло, я тоже проверил

ага.

я значит отладочную по ошибке коммитнул

хм, у меня по ассету и один DGS3100 отвалился

все от удаленных объектов из моделей в инвентори

2014-05-29 09:07:36,285 [inv.discovery: asset_discovery(gw-baz)] Creating new object. model='Cisco | 7300 | 7301 Chassis', serial='74836317'

2014-05-29 09:07:36,309 [inv.discovery: asset_discovery(gw-baz)] Changing object management to 'gw-baz'

2014-05-29 09:07:36,321 [inv.discovery: asset_discovery(gw-baz)] Changing name to 'gw-baz'

2014-05-29 09:07:36,364 [inv.discovery: asset_discovery(gw-baz)] Creating new object. model='Cisco | 7200 | NPE-G1', serial='JAE1039CD6M'

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

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

сучка однако

смоотри что у меня в 7301 ещё нашлось

{

"vendor": "CISCO",

"description": "Serial",

"part_no": [

"PA-4T+="

],

"number": "1",

"builtin": false,

"serial": "33378550",

"type": "MOTHERBOARD",

"revision": "N/A"

},

ну и?

почему оно motherboard?

это такой скрипт

вот поэтому я и просил вынести типы в модели

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

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

а нок верит скрипту, а не базе

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

хотя бы с точки зрения longest match

тип в базе явно привязан к part no

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

ну посмотри в asset.py

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

почему

кстати у меня нет коннектион тайп для 7300 серии

подумай, где там можно сделать проверку

e_zombie: это 7200

if type is None:

type = m.cr_context

там, наверное, по другому надо

http://pastebin.com/L01ETDX4

e_zombie: cr_context ему еще поставь

это тип

ээээ?

какой должен быть

по другим картам смотри

zi_rus: если в моделях все типы пробиты, то можно в скрипте просто возвращать None вместо типа

dvolodin: http://www.cisco.com/en/US/products/hw/modules/ps2033/products_data_sheet09186a0080091cd2.html

да я знаю ее - 4 ешки

а мне они все на одно лицо.

какой тип рисовать

спроси у того, кто 7200 рисовал

LINECARD вроде

да. походу

будет воткнут в linecard{N}

2014-05-29 10:01:53,843 [inv.discovery: asset_discovery(gw-pet)] Creating new object. model='Cisco | 7300 | 7301 Chassis', serial='JAB092006TF'

2014-05-29 10:01:53,867 [inv.discovery: asset_discovery(gw-pet)] Changing object management to 'gw-pet'

2014-05-29 10:01:53,899 [inv.discovery: asset_discovery(gw-pet)] Changing name to 'gw-pet'

2014-05-29 10:01:53,916 [inv.discovery: asset_discovery(gw-pet)] Unknown part number for Cisco 7301: PA-4T+= (Serial)

я добавил коннектон тайпы для 7300

и поменял профили.

в тесте оно коннектит но на живом железе как то хер.

в рулах глянь

https://dpaste.de/Xi8d

zi_rus, e_zombie: вот так примерно

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

да, для отладки правил есть фишка noc-discovery

[beef]

asset_discovery.mx80-1 = 2737fc92-6af6-47ad-803b-db205d09d670

asset_discovery.mx480-1 = 0198932c-af0e-4f94-8513-c7dd11b64b25

asset_discovery.mx480-2 = b824a8f0-3127-4965-848a-6ff309be962f

asset_discovery.mx960-1 = 830cf1ed-2a99-4c57-b3f0-1ad7dd40bf0c

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

тогда при запуске соответсвующего метода discovery он не будет лезть на железку, а возьмет результат из тушенки

=)

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

запускается вкладка Discovery в managed object

Дим, а какой механизм распространения-обмена солюшенами планировался?

репо отдельный?

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

_4ePTeHok: над разными думал

отдельные репо, яйца/колеса

вообще какой-нибудь market

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

тоже чото забили

qa глобальный есть

questions называется

то на сайте

я про встроенный в нок

там портал нужен отдельный, с которым инсталляции NOC будут общаться

патчик для asset_discovery проверяйте

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

буду в оффлайне

так что проверяйте коммит

есть еще один для check_link с настройками его

e_zombie:

"name": "Cisco | 7300 | Serial PA-4T+= ",

"uuid": "7948b78d-9d0a-449b-946a-9d5c5001a0f1",

"vendor__code": "CISCO",

"description": " Serial PA-4T+= module",

пробелы лишние потри

и = у киско -- spare part

можно выкинуть

dvolodin: Касательно вчерашнего. Как мне привязать выполнение "noc.fm.handlers.event.discovery.schedule_discovery" только к определенному селектору?

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

а еще более правильно -- настроить object profile

и что там будет в профиле?

ааа

да

dvolodin, вот кстати, смотри, нок подавляет линк ап как дубликат, но почему check link не закрывает аларм?

а, ну понятно

потому что для IOS XR нет скрипт get_interface_status

dvolodin: Дим, можно ли в object profile для discovery сделать что-то типа "run once" или "run manual", чтобы не извращатся, придумывая интервалы в 10 лет ?

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

Dmitry1, а тебе религия не позволяет прописать 10 лет как период?

Можно ли на общей панели для MO добавить кнопку "change object profile", чтобы я мог выделить кучу объектов, и одним движением мыши поменять им auth profile

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

1. Это не очевидно

да ладно

2. Это действительно костыли

это такая настройка

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

разные данные имеют свойство меняться

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

zi_rus: а разве такая настройка на 10 лет не отработает при перезапуске нока?

TSergey, не должен

а если так делает то это баг нока который надо фиксить

Есть такие свичи, как DES-3526, у которых ключ ssh генерится процессором, и при каждом заходе на свич загрузка CPU возрастает до 100%

мне какжется Dmitry1 прав, а ты уперся :)

Мне надо, чтобы MO был "is managed". но скрипты на нем выполнялись только тогда, когда я захочу

и накатить профиль на выделенные объекты --- каждый тут, я уверен, делал это не один раз, но в шелле

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

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

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

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

не надо добавлять функции

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

настройка простая как яйцо

zi_rus: ну так-то да, а если мне нужно десяток (150) железок временно не опрашивать?

я не понимаю зачем 2 недели с этим ебать мозги

zi_rus: У меня сейчас стоит для длинков интервал около 10 лет

стартуем NOC

и читаем

то, как предлагает Дима, это решает (двумя способами)

2014-05-05 14:51:08,210 Script DLink.DxS.get_lldp_neighbors(10.116.0.42). Timeout set to 120

2014-05-05 14:51:08,210 1 script threads (50 max)

2014-05-05 14:51:08,215 Script DLink.DxS.get_version(10.116.0.33). Timeout set to 120

2014-05-05 14:51:08,216 2 script threads (50 max)

2014-05-05 14:51:08,220 Script DLink.DxS.get_inventory(10.116.0.252). Timeout set to 300

И так - несколько экранов

что и следовало доказать

Dmitry1, вот этим и надо ебать мозги dvolodin. почему нок при старте запускает дискавери которые запланированы на дальне будущее

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

это и надо исправлять

zi_rus: настройка должна быть очевидной, 10 лет --- это обман

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

Он говорит, что нужно писать solution или handlers, которые будут "давить" ненужные скрипты

TSergey, это не обман, это вполне логично

zi_rus: Сейчас "вполне логичное" не работает

это баг или фича

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

TSergey, не только ручной, но и триггерный

вот пример

и не обман?

у меня ASR9k присылает сообщения config changed

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

теперь я задрал период до 1 месяца

хотя стоит 10 лет

ибо теперь мне не надо собирать конфиг каждый день

Значит настройки там - обманка

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

zi_rus: ну содасись же уже :)

*согласись

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

*существующей

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

это базовое понятие от которого стоит исходить

run once не вписывает в это понятие

как раз вписывается

нет

совершенно нет

zi_rus: совершенно да :)

у меня свич в 1 юнит. Там никогда не будет меняться конфигурация запчастей

такое возможно

Зачем мне выставлять какой-то период на него для asset_discovery ?

а возможно там будут втыкаться sfp

А он не умеет определять SFP, и никогда не научится их определять.

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

и ты никогда этот свич не заменишь на тот который сможет?

ну это у тебя

а мои все это могут

так об этом и речь, что тебе такая настройка не нужна

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

Ну так давай вообще выкинем все профили из SA, кроме цисок

Потому что у тебя только циски

или module inserted которые должны быть триггерами для дискавери

нет

нет

нет

бля

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

и вообще ничего не могут

zi_rus: ты не представляешь сколько народу в личке спрашивают не решена ли проблема с link_discovery по DLink`у

кроме цисок - еще около 40 вендоров

TSergey, и какая там проблема

а ты не знаешь?

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

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

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

каждый раз когда поднимается эта тема мы приходим к длинкам

и их проблемам

TSergey: А они там у себя в Москве сидят на ентерпрайзе, и все оборудование, что за МКАД'ом, считают "сраными длинками"

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

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

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

надо решать

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

надо решать

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

zi_rus: если нужен профиль с доступным дискавери, но не по расписанию --- ?

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

приведи пример почему ЭТО возможно в идеологии дискавери?

отсутствие расписания. зачем?

zi_rus: напиши мне solution, запрещающий discovery при старте, давящий джобы check_link, привязывающий "noc.fm.handlers.event.discovery.schedule_discovery" к селектору, тогда и будем решать остальные проблемы

Привожу - Железка ставится один раз, и ее конфигурация меняться не будет. А если и будет - должна быть возможность запустить discovery вручную

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

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

zi_rus: а почему дискавери == шедулер? почему нет другого метода запустить дискавери? почему опрос железки это обязательно периодическая операция?

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

Патамушта акваланг

да

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

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

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

TSergey, я в четвертый раз повторю, дискавери имеет периодическую природу сам по себе

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

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

Мне не нужны настройки. Я хочу запустить его один раз

ну ты вообще...

это, кстати, было бы логично запускать из SA\MO\Edit\discovery --- без оглядки на то, как он метод настроен в профиле

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

если я уже зашел в SA\MO\Edit\discovery, почему в нем-то недоступен метод для запуска?

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

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

если я уже зашел в SA\MO\Edit\discovery, почему в нем-то недоступен метод для запуска?

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

Потому что наши хотелки логичные

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

Dmitry1, а я говорю что они не логичны

твое слово против моего

может проголосуем?

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

*вариант?

Я не предлагаю свой вариант

Я предлагаю вариант, который бы устроил всех

Чтобы можно было скрипты запускать как один раз, так и по расписанию

TSergey, мой вариант не единственный, но он логичный, вы до сих пор не привели ни одного аргумента за свой вариант, кроме ХОЧУ

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

мне кажется, что в существующем уже коде, если дать запусакть метод запрещенный в профиле в SA\MO\Edit\discovery, то это как раз даст возможность один раз опросить желеку, без извращений с профилем

*запускать

А оно сейчас не хочет запускать, если у тебя метод отключенный

ага, именно так

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

это бы было логично со всех сторон

это избыточный функционал

для меня нет

и для меня нет

знаешь, прежде чем что-то сделать, подумай почему этого делать не стоит

я не знаю, почему стоит запрещать запускать discovery вручную

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

ты не ограничен в этом

ты можешь активировать метод дискавери

zi_rus: хихик. иногда нок делает, а не думает, почему не стоит.

и запускать его руками сколько захочешь

Как только я активирую этот метод, NOC сразу же начнет ломиться на все железки с таким же auth profile

не auth, а mo profile

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

это да

это как раз те проблемы которые и надо решать

run once - костыль

а запуск в SA\MO\Edit\discovery --- это чем плохо? кроме твоих религиозных убеждений :)

почему

активируй и запускай

никто не ограничивает

(11:34:12) Dmitry: Как только я активирую этот метод, NOC сразу же начнет ломиться на все железки с таким же auth profile

да, начнет

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

для этого профили и созданы

я нажимаю в SA\MO\Edit\discovery и вижу ответ

если бы можно

TSergey, проверки это уровень лабораторий

а сейчас, это отдельный профиль

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

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

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

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

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

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

это нужно

иногда пингование отдельных железок надо отключать

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

иногда еще что

НО

причем тут run once

вас понесло хер пойми куда

он же не проверет существующий линк? где же периодичность?

*не проверяет

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

а один раз для ассета --- моветон

zi_rus: Смотри ситуацию. Есть пользователь, которому ЗАПРЕЩЕНО менять MO. Но ему нужно запустить discovery

да и вообще ассет у меня не работает после удаления моделей :(

бляяя

zi_rus: это работа

а, у вас тут опять срач

Dmitry1: а разве разграничение прав работает в ноке?

zi_rus, справляешься?)

dvolodin, иди сюда, давай сам оттдувайся, я устал, пойд обедать

гг

_4ePTeHok: а ты часом в нок-шедулер не умешь?

чего умею

я куда угодно умею

смотря что

у меня тут вообще ощущение, что на канале анархея вторую неделю)

_4ePTeHok: у меня более-менее регулярно случается NOC-1331

любители ручников атакуют

про длинки и ссш так это вообще весело

включите блядь уже телнет штоли

врубите на них telnet, если ssh там нерабочий

дада

телнет видимо тоже виснет

и виноват в этом NOC

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

взял у босса билетик, залогинился

:)

dvolodin, Дим, глянь плиз NOC-1331

dvolodin: почему логически неверно дать запустить метод в SA\MO\Edit\discovery, если он не включен в профиле? Я же уже на железке, как бы понимаю чего делаю, консоль, скрипты, а дискавери нельзя?

потому, что это может быть запрешено административно

скажем не переживает железка действий скрипта

потому профиль такой и стоит

а твой сотрудник зайдет и повесит

он и криптом завесит тогда, нет?

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

бля

есть разница нихуевая такая

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

между дискавери

и скриптами

дискавери - это автоматическая периодика

_4ePTeHok, дискавери пользуется скриптами

zi_rus: да и так нихрена не работает, так хоть видно быстрее чего не так

а скрипт - это просто еденица

низкоуровневого взаимодействия

zi_rus, пользуется, но это не одно и то же

вопрос частоты

серипт не пишет в базу результат

это ключевое отличие

скрипты надо убрать из морды, я так считаю

он только выводит его в морду

_4ePTeHok: хорошо, есть у тебя предложение, как один раз собрать инфу по железке и потом ее не трогать? ну критично там по логам или загрузке?

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

где метод включен

И пиздец

через сутки - переключаешь

Половина сети в дауне

да блядь

Это жизнь такая

У меня тысячи этих длинков

и чо

ты тысячи заводишь?

И менять их на циски не будут

каждый день

_4ePTeHok: тогда такой дефайлт должен быть настроен на десятилетний срок

бля.

ок

смотри

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

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

Который подразумевает, что это циска

def_prof_mo. с периодом 10 лет.

Dmitry1, дай сказать, задолбал ныть

в этот профиль по дефолту добавляются все железо

там включены методы которые вам надо одноразово выполнить

_4ePTeHok: и время выкручено на максимум? это логичная настройка, да?

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

все

(11:52:00) _4ePTeHok: там включены методы которые вам надо одноразово выполнить

Еще раз. Дискавери - это периодика через шедулер

_4ePTeHok, это еще большая шиза чем то что они предлагают

и от этого вы никуда не денетесь

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

Это именно то, чего мы хотим

если там стоит период раз в месяц - оно один раз и выполнится

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

дык это ж для вашего железа оно такое безопасное

у меня ежики вон и по периодам раз в 5 минут живут совсем дискавери

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

тоже говно

_4ePTeHok: При запуска NOC запускаются все дискавери, независимо отвыставленного периода

и

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

_4ePTeHok: при событии "config changed" запускаются все дискавери, независимо отвыставленного периода

и переключить

_4ePTeHok: читай выше. NOC чхать хотел на период дискавери

dvolodin, ты с офм закончил? можешь реальными проблемами заняться?

он в отпуск

сказал же

_4ePTeHok: мне кажется более логичным давать запустить из SA\MO\Edit\discovery, а безопасность, о чем ты пердупредил, нужно как-то еще обеспечить

TSergey, еще раз - там периодика

нету там понятия счетчиков

склько раз когда то посылалось

в шедулер

скажи, чего периодического в кнопке Run?

_4ePTeHok: нету там никакой периодики. NOC запускает все discovery при своем старте и при событии "config changed"

короче

четко и по пункту - что вы хотите?

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

т е параметр - действие

запуск метода в SA\MO\Edit\discovery, вне зависимости от профиля

запуск метода в SA\MO\Edit\discovery, вне зависимости от профиля

для моих задач --- выше головы

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

хорошо-бы еще что-бы вне зависимости от noc.conf --- но понимаю, что это слишком

а теперь вопрос

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

идет в мо-едит, выставляет профиль

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

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

что он думает?

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

верно. что профиль - это какая то хуета, что не работает.

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

в профиле выставляются параметры для шедулера

да нет. там есть столбик профиль

с галками и крестиками

это управление шедулером

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

ну т.е. это по факту так

с вашими пояснениями что дискавери это периодическая задача

должен обозначать не то, что это разрешено в профиле

а что бля

типа (auto\manual)

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

так в Run разве лезут включить? запустить ведь

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

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

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

ну давайте уже соглашайтесь, логично же

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

_4ePTeHok: Уже есть куча скриптов discovery для разных профилей. Уже написано ядро NOC'а, уже работает супер-пупер шедулер, но вот вынести кнопочку "запустить скрипт" мы не можем

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

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

(по возможностям пользователя что-то делать)

Раньше я смеялся над этим, но когда начал работать с NOC, понял, что это грустная правда http://yun.complife.ru/miscell/winwars.htm

freeseacher: про stale discovery --- не попадают те, у кого discovery включен, но ни разу ничего не нашлось

ну это логично же

я спецом их убираю из списка

ну сил опять убеждать у меня уже не осталось :)

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

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

freeseacher: да, выполнялось и в Fail

и в staile нету

вижу для четырех коммутаторов, config_discovery, interface_discovery? lldp_discovery

по ним Fail (и ни разу успешно не выплнялся) и в stale не попадает

по поводу кнопки ран

вовсе ее удалили? :)

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

на текущее

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

utils.refresh_schedule("inv.discovery", "config_discovery", <id>) --- отрабатывает зависимо от профиля?

а нет, стоп

r = json_decode(request.raw_post_data).get("names", [])

d = 0

for cfg, name, method in self.DISCOVERY_METHODS:

if getattr(o.object_profile, cfg):

if name in r:

self.ensure_discovery_job(name, o)

start_schedule("inv.discovery", name, o.id)

refresh_schedule("inv.discovery",

name, o.id, delta=d)

любой дискавери зависит от профиля

ибо метод API там один

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

возможность запуска скриптов вручную уже есть

Dmitry1: вот это utils.refresh_schedule("inv.discovery", "config_discovery", <id>) --- отрабатывает зависимо от профиля?

или нет?

я не знаю. я так глубоко в NOC не лез

Dmitry1, что значит просто скрипт?

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

add_vlan, get_fqdn и т.п. Скрипты, которые находятся в sa/profiles

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

и даже обработка возвращаемых значений

_4ePTeHok: utils.refresh_schedule("inv.discovery", "config_discovery", <id>) --- отрабатывает зависимо от профиля?

от галки, что но включен?

*что он?

Dmitry1, это совершенно не то

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

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

Сейчас у нас несколько механизмов: pyrules, триггеры, jobs, handlers, solutions, скрипты из MO

Костыль на костыле

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

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

проверил, utils.refresh_schedule не отрабатывает, если метод выключен в профиле

проверка глубже

Dmitry1: можно расслабиться, без пересмотра подхода это не прикрутить

Я и предлагал это

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

Дим, ты предлагал поднять сложность настройки NOC до уровня, практически, DBA

Не совсем.

Просто часть действий "по умолчанию" сделать с возможностью конфигурации

Тем более, что наш WEB может рисовать что угодно

в общем проверка идет действительно по нажатию кнопки

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

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

_4ePTeHok: хм, я проверил на utils.refresh_schedule("inv.discovery", "config_discovery", <id>) --- с отключенным профилем конфиг не собрался

_4ePTeHok: Лишний способ сделать что-то никогда не помешает

TSergey, это и подтвержает

что проверяется профиль

if getattr(o.object_profile, cfg)

вот эта проверка

значит сделать так: if (getattr(o.object_profile, cfg) and pressed_key):

ой

какой еще кей

or pressed key

это апи при нажатии кнопки

переменная, которая туда передастся, если кликнули мышкой по run now

_4ePTeHok: TSergey, это и подтвержает

погоди

from noc.sa.models import *

from lib.scheduler import utils

mo = ManagedObject.objects.filter(name='s644-1-1.intt')

for m in mo:

print m.name

result=utils.refresh_schedule("inv.discovery", "config_discovery", m.id)

какой Run? вот так не отработало

с включенным в профиле --- работает

ты переносишь уже существующую задачу

а не новую добавляешь

if getattr(o.object_profile, cfg):

if name in r:

self.ensure_discovery_job(name, o)

start_schedule("inv.discovery", name, o.id)

refresh_schedule("inv.discovery",

name, o.id, delta=d)

dvolodin, как инвентори предполагает располагать клиентские cpe по адресам? я же не буду РоР под каждого клиента делать

и не надо

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

в заявке

и хватит этого

_4ePTeHok: start_schedule("inv.discovery", name, o.id") --- новая? круто, попробую

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

что логично

_4ePTeHok: не, что-то старт как-то не так отрабатывает, и при включенном не добился заливки конфига

dvolodin, но они в ноке заведены и отдискаверены

и даже волокна в кабеле занимают

если волокна занимают, то чем тебе не PoP ?

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

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

у нас некоторым клиентам ставят 2960 на 8 портов

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

клево

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

hektp

а у клиента нечем пару вланов разобрать

они под нашим управлением

и в ноке висят

хотя бы для сбора конфигов

ну еще я asset discovery для них включил

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

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

а если клиент включен такой штукой в ТЦ

где тоже есть мой узел

и не один

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

можешь, действительно, кидать в отдельную папку

у тебя список адресов установки есть?

примерно есть

то есть буквально 2 колонки -- адрес, имя managed object

и замолчал... а я ен понял мысли

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

ну в попингуй их точно добавить можно

вот из попингуя их точно удалить можно что я и сделал

нок берегов не видит

шлет алармы на все подряд

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

дергает геокодинг

создает в нужном месте соотвествующий PoP

я вижу костыли

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

ну а для новых PoP руками создашь

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

типа чтобы нормальный узел не строить

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

типа железка стоит тут

адсл модемб роутер или cpe

я планировал еще сделать PoP | Client

*свич

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

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

с уровнем 10

dvolodin, недоузел подразумевает что он недо-

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

ну почему же

PoP -- графический объект

что это за РоР если в нем одна железка

без стойки, шкафа или иного

ну вот просто железка

это уже неважно

там может и шкаф быть

или кросс

может и быть, но это клиентский шкаф и кросс

как раз недавно один клиент был

не суть важно

смотри

ему эти 2 2960 притащили

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

PoP -- это контейнер с координатами

он и говорит че вы за хуйню притащили

который видно на карте

че мне с ней делать

и еще у него есть линки между PoP

стали на складе искать полки для шкафа

логика есть, но это такой геморой

при массовостиъ

ну а какие еще варианты?

можно и solution сделать

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

но не стоит

либо просто контейнер для CPE

неграфический

в принципе у меня нет массового распространения cpe. думаю я переживу

я думаю, оно скорее пригодится для PoN в частном секторе

когда у клиента ONT, никаких шкафов нет, но оптика по деревне проходит и ее хочется видеть на карте

14-05-29 13:19:47,600 [inv.discovery: asset_discovery(br-sar)] Connecting MSFC None:in -> SUP 5:msfc

2014-05-29 13:19:47,607 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | DFC - Cisco | 6500 | MSFC

2014-05-29 13:19:47,607 [inv.discovery: asset_discovery(br-sar)] Connecting PFC None:in -> SUP 5:pfc

2014-05-29 13:19:47,614 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | DFC - Cisco | 6500 | PFC

2014-05-29 13:19:47,615 [inv.discovery: asset_discovery(br-sar)] Connecting FAN 1:in -> CHASSIS None:fan1

2014-05-29 13:19:47,628 [inv.discovery: asset_discovery(br-sar)] Connecting PSU 1:in -> CHASSIS None:psu1

разъемы должны быть одинаковых типов

чтобы соеденить

посмотри как в 6500 сделано

у мсфц

всё весело а что за железка не прицепилась?

что то вывод какой то упоротый.

Connecting MSFC None:in -> SUP 5:msfc

[14:28:13] <e_zombie> 2014-05-29 13:19:47,607 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | DFC - Cisco | 6500 | MSFC

с одной стороны дырка Cisco | 7600 | DFC

с другой - Cisco | 6500 | MSFC

а какую модель править? то

чёто я е помню чтобы я так косепорил

ну на мсфц разъем мсфц

на супе - ответка под него же

пфц это ж отдельно

Cisco | 6500 | WS-F6K-MSFC2Cisco Systems MSFCCisco WS-F6K-MSFC2 Daughterboard

{

"vendor": "CISCO",

"description": "7600-MSFC4 C7600 MSFC4 Daughterboard Rev. 1.4",

"part_no": [

"7600-MSFC4"

],

"number": "None",

"builtin": false,

"serial": "JAE1350QTE5",

"type": "MSFC",

"revision": "000"

},

по идее это вот эта штука не прицепилась http://bt.nocproject.org/browse/INV-34?filter=-2

"type": "MSFC", на железке. а в модели DFC

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

зачем?

что это за суп?

патчик для asset_management проверили?

http://i62.fastpic.ru/big/2014/0529/9d/9ea0fc718ee7a2077bb7d06476a8679d.png

вот эта железка.

dvolodin, я проверил, чего-то изменилось, но мне не помогло

7600-MSFC4 C7600 MSFC4 Daughterboard Rev. 1.4" шняга втыкаться не хочет.

http://bt.nocproject.org/browse/INV-34?filter=-2

это её модель

cr_context DFC -- неправильно

а что?

сделай MSFC

и в connection rules добавь

{

"name": "Cisco | 7600 | MSFC",

"uuid": "21a200f0-dc3d-4346-b931-8e5a96c9a9fb",

"description": "Cisco 6500/7600 MFSC",

"c_group": ["7600_fabric"],

"genders": "mf"

}

не прокатывает

тип MSFC пихается в слот msfc

dvolodin, http://pastebin.com/iLFCpYvr - почему я вижу шасси и два блока питания в нем, но не вижу МРА в шасси

еще там какое-то говно с вентилаторами, но пока речь про МРА

2014-05-29 16:39:05,628 [inv.discovery: asset_discovery(br-sar)] Connecting SUP 5:in -> CHASSIS None:sup5

2014-05-29 16:39:05,644 [inv.discovery: asset_discovery(br-sar)] Connecting MSFC None:in -> SUP 5:msfc

2014-05-29 16:39:05,650 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | MSFC - Cisco | 6500 | MSFC

2014-05-29 16:39:05,651 [inv.discovery: asset_discovery(br-sar)] Connecting PFC None:in -> SUP 5:pfc

2014-05-29 16:39:05,658 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | DFC - Cisco | 6500 | PFC

2014-05-29 16:39:05,659 [inv.discovery: asset_discovery(br-sar)] Connecting FAN 1:in -> CHASSIS None:fan1

2014-05-29 16:39:05,672 [inv.discovery: asset_discovery(br-sar)] Connecting PSU 1:in -> CHASSIS None:psu1

2014-05-29 16:39:05,685 [inv.discovery: asset_discovery(br-sar)] Connecting PSU 2:in -> CHASSIS None:psu2

Cisco | 7600 | WS-SUP720 вот ещё смотрю там выставлен типа соединения Cisco | 6500 | MSFC

кто мне ответит почему в платах для 76 стоят конекшен тайпы для 6500

я конечно понимаю что если плата подходит для двух серий то... но ....?

а почему они должны отличаться?

:)

железка-то одна и та же

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

на супе рисовать конекшен тайпы для двух вариантов или на нашлёпе

да

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

Cisco | 7600 | RSP720-3CXL-GE

Cisco Systems

SUP

RSP720-3C-GE 2 ports Route Switch Processor 720 with PFC-3CXL

Cisco | 7600 | RSP720-3C-GE

требуют правки.

они встроенные.

а это 720 вообще в 65 серию вставить то можно?

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

можно как-то форсануть

без передобавления

оно просраться должно

через какоето время.

ну я делаю run discovery

now

плюс смотри профайлы у тебяб там всё настронено?

да, отключал свитч для перепрошивки

все функции работают в scripts

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

тпм бывает шедулер нагружен

пока разгребет задачки

у меня на режим выходит минут через 5 -10

хочешь форснуть - перезапусти нок и еще раз ран дискавери нау

даже в логах пусто noc-discovery

dvolodin: и "./log/noc-discovery.log.8:2014-05-28 13:19:30,350 [inv.discovery: asset_discovery(br-sar)] Failed to connect: Incompatible connection types: Cisco | 7600 | DFC - Cisco | 6500 | MSFC" сделать более информативным. вывести название обьъекта чтобы было понятно откуда копать и куда.

ну же написал

он тебе более чем информативно написал

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

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

во, после ребута вроде пошел, спасибо

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

ты пытаешься воткнуть MSFC в дырку для PFC

Connecting MSFC None:in -> SUP 5:msfc

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

мне интересно КАКОЙ БЛЯТЬ ОБЪеКТ пытается законнектиться. для этого мне надо слазить в инвентори. открыть объект. найти список линейных карт. посмотреть что там может быть этого типа и тд. и потом лезть смотреть модель. упростите вы мне эту задачу.

всё я ушёл по бабам.

потом фото в студию.

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

dvolodin, про отчеты http://dhcpd-pools.sourceforge.net/

там есть что-то выдающееся?

ну не знаю, я за саму идею зацепился

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

это бы превентивно отслеживать

OFM умеет

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

в пулах

хорошая попытка, но нет

офм не нужен

:)

ку

зи

скажи что там с архивом в ФМ

щас дропает через промежуток?

или как там изменили

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

пни куда глянуть

в конфиги

noc.conf или где-то там

я не помню

ок

сп

скоро с длинками заеду

прочитав логи жду ада =))

просто некоторые нагнетают

я держал какое-то время длинки в ноке

с снмп проблем не было

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

да. знаю

и ssh 100% cpu и snmp

готовить его сложно, но можно

про длинк

нагнетают это мягко сказано