nocproject.org

hi all

кто Zyxel.ZyNOS.get_switchport пилил?

косячок-с

доброго всем

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

определенно

и кто как выкручивается?

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

да

у меня тоже

железяки не удаляются

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

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

dvolodin как дебагить скрипты, которым параметры нужны?

dvolodin add_vlan например

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

vlan_id=10

и в том же духе

dvolodin в коммандной строке?

да

пришла вчера в голову хорошая идея

dvolodin: как _правильно_ удалить из нока объект?

как довесок к vc management

в общем, ничто не мешает нам показывать интерфейсы, на которых поднят конкретный vlan

можно сделать по аналогии с managed object > interfaces

> addresses

KTO-TO_: а можешь слабать аццкое приложение на ExtJS ?

dvolodin: какое? :)

сейчас попробую нарисовать

глянь пока последний коммит мой с inv/apps/interfaces

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

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

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

dvolodin а может быть такое что command_submit не используется в self.configuration?

.configure*

zi_rus_: уже не виснет

это хорошо

dvolodin: А что именно смотреть? 5376?

как я и думал...object is referenced from <class 'noc.fm.models.ActiveEvent'>

KTO-TO_: NOC-216 посмотри

http://code.nocproject.org/changelog/noc?cs=effe78d7b833e85ab4716d0592747505b478871e

смотри, идея такая

discovery кладет интерфейсы в базу

На вкладке L2 - vlan'ы или те же физические интерфейсы?

те же физические

на первой вкладке -- только порты

l2 -- порты и port-channel'ы в разрезе switchport

l3 -- ip интерфейсы, включая SVI

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

это разные типы запросов

условно /inv/interface/<object id>/l1/

и /l2/ и /l3/

при запуске приложения выбраешь managed object

если в нем несколько forwarding instances -- появляется выбор instance рядом

т.е. надо запрос еще на forwarding instance

да

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

В приципе поняно. Надо хрень - которая может по json'у построить grid :)

да

на самом деле - 3 грида

Будем делать :) Осталось найти время и данные для теста.

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

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

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

про шаблоны думал, да

следующий этап

dvolodin: Для начала так и сделаем. три отдельные вкладки. Каждая про свое и со своим. Потом зарефакторим. Если получится :)

потом оно будет периодически дергать через json get_interface_status и рисовать лампочки в первой колонке

ДУмаю, что на следующей неделе у меня посвобоней будет со временем и займусь.

а дальше -- появятся действия на интерфейсах

типа кинуть порт в vlan

положить / поднять

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

еще дожить надо :)

А данные сейчас есть для l2, l3?

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

да, есть все

jr/

ок.

подозреваю, что это будет самое популярное применение noc

Ага. У нас похожий инструмент тех.поддержка во всю использует :)

угу

в итоге он будет одной из морд к vc provisioning

кинул интерфейс в vlan - все сделало

dvolodin а как с port vid быть? iaddvlan расчитан только на тегированые

уберем их оттуда вообще

задача add vlan -- создать vlan на свиче

будет интерфейс, который делает на порту vlan tagged или untagged

в staticvlan есть похожее

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

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

Ну что, давайте к релизу таки готовиться?

с NOC-36 у нас что?

У нас с NOC-36 всё плохо.. Профиксили только мак для get_chassis_id.

get_arp - не рабочий, для примера можно раскоментировать его в Linksys.SPS2xx & Eltex.MES

Тоже не работает get_mac_address_table.. Примеры тамже.. (Но с этим есть проблема - несовсем понятно как взят привязку к vlan)

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

snmpwalk -v 1 -c public 10.8.23.131 1.3.6.1.2.1.17.7.1.4.3

это даст хорошую возможность написать get_switchport & get_interfaces универсально через SNMP!

dvolodin_: My users ask if it is possible to generate RIPE netname registrations from the IPAM part... What do you think of that?

inetnums ?

and by netname I mean inetnum

(-: http://pastebin.com/CcsUsfzT

с NAWS у нас все нормально?

dvolodin_ от железа неверна зависит

okay, I'm a little confused over configuration management. I've added a device under service activation, and I'm trying to fetch its config from configuration management, though nothing happens, and it just says waiting

NOC-218 -- по моему, хорошая идея

Eising: do you have sae/activator running?

yes, 4718 ? S 23:11 /usr/bin/python ./scripts/noc-sae.py launch -c etc/noc-sae.conf -i 0

hmm

no process called anything with activator

check etc/noc-activator.conf and look at Service Activation > Setup > Activators

right. The activator doesn't start. I'm looking into that. Thanks :)

noc-launcher.conf

well, it was a permissions problem

argh

yes, snmp traps and syslog

dvolodin_: this keeps looping in the log: http://pastie.org/3020267

yes, look at Service Activation > Setup > Activators

activator name, secret and address must match both in noc-activator.conf and in database

ah, got it

and it works. Thanks again :)

dvolodin_: do you have any guides on adding new sa functions?

For instance, most provisioning seems to be of vlans, which makes sense in a switched network, but our network is almost entirely routed...

Eising: only code as guide :(

okay

Try to understand what is map/reduce task

then with ReduceTask.create_task you can implement almost anything you want

do not hesitate to ask

Okay, I'll see what I can find out

also we have a plans to implement workflow engine within NOC, for high-level integration and activation processes

It is more high-level scripting logic, than pyRules

right. It would be great if nocproject eventually can take of all provisioning in my network... I'd like to have a configuration-free network :)

workflows looks like a final point

great

you describe processes like -- activate customer/ deactivate, add/remove server and so on

initiated from NOC's UI or by signal from external system

that would be quite cool

I'm worried about how complex those rules will be to handle my network, and how much I need to clean up first :)

We've more than 50 stages to connect the customer ;)

:)

чего-то я не понял последней фразы

Боюсь даже представить себе 49-й способ.

:)

50 стадий подключения

Ну, я имел ввиду 49-ю стадию :)

серьезно, 50?

да

1 стадия - сначала отделили свет от тьмы... :)

1. подобрали правильное слово

:)

на 49-й стадии отделяем агнцев от козлищ

на 50-й -- мочим козлов

:)

на 50й должен быть конец света.

это при отключении

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

я не о том конце

не электрического в общем

=)

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

после него не буедт ни вконтактиков ни клиентов)

но звонки останутся

:)

http://code.nocproject.org/changelog/noc?cs=b4edba1250848baeaffbe67048048933c44b9b46

как вам патчик