nocproject.org

кто там коммитов жаждал

hg diff | wc -l

2216

:)

эт ты чего туда влил?)

ох е. джанга

хотя там маловато чото

да не

django там просто security update

order management там

на подходе

https://bitbucket.org/nocproject/noc/commits/02bf4def92b8a59f0969080e95c54c6295a2952f

вот, один из важных моментов, наряду с termination group

покрытие

объясни как пользовать?)

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

причем крыть можно как здания с точностью до подъезда, так и контейнеры в inventory

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

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

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

делаем новое покрытие, включаем в него эти подъезды, как место продажи

и порты, как объекты для продажи

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

есть

хм. значит не доглядел

открой здание

обновляюсь)

там есть грид с подъездами

давно уже оно

о блин, меркуриал обновили..

Entrances

кстати по инвентори - как смотришь на то, чтобы даты добавить к свойствам объекта? Лог это хорошо, но смотреть не очень удобно. Скажем first_discovery_date\change_date\install_date - вбиваемое вручную. Чтобы сразу было видно когда куда переехало

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

ага, я понял суть

там не все так просто

есть еще технологии

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

скажем IPoE и PPPoE

ага, у разных технологий разная дальность

ну и клиенты разные

могут быть

и процессы могут быть разные

вообще там уже и сервисы надо

т е услуги

сервисы в OFM есть

м..это где?)

хм. мибы не влились

noc.fm.models.error.OIDCollision: Cannot resolve OID 1.3.6.1.4.1.9.1.1285 collision between CISCO-PRODUCTS-MIB::ciscoCDSISM and CISCO-PRODUCTS-MIB::ciscoCDSAVSM. No preference for CISCO-PRODUCTS-MIB

upgrade-user: 65: sync-mibs failed

http://pastie.org/9139309

вот оно

там есть такое понятие, как ресурс

который может быть связан с заявкой

http://pastie.org/9139311

статическое выделение ip'шника из пула сделал уже

ох сколько там всего.

по мибам как поступать?

поранжировать его

я думаю, CISCO-PRODUCTS-MIB::ciscoCDSAVSM менее приоритетен, чем CISCO-PRODUCTS-MIB

мм.. это Дима там добавлял вроде

а

там хуже

там в одном MIB'е колизии

мде, и ето не китайцы а циско.

поправил

теперь будет игнорировать коллизии в пределах одного MIB'а

да, проехало

а как подразумевается именование coverage-й правильно строить?

типа имя pop?

кстати это идея - привязывать pop к покрытию

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

кому-как

там еще и технология может быть

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

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

просто это одно из срезств автоматизации создания поп

можно и множественную

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

да, надо же геокодер наваять

..

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

на самом деле покрытие можно создавать при создании managed object'а

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

ну..оно там не всегда надо

я сделал геокодер для OSM

но он лажает сильно

смотри - у маршрутизаторов ядра - как быть с покрытием?

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

_4ePTeHok: смотря какие услуги ты продаешь с маршрутизатора ядра :)

в том то и дело - что напрямую обычно никаких

большая редкость скажем мплс

ну и покрытия у него нет

это ручник

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

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

не надо

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

перелогинивался

создавать по профилю

да, по профилю удачнее

там пока нет editor'ов в grid'е

а, понял)

:)

наверное, я в форме зданий добавлю покрытие

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

и plugin для контейнеров в inventory

собственно, solution'ы позволяют зацепиться за создание и изменение объектов

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

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

(размечтался)

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

и аггрегировать по районам(еще больше размечтался)

а гис умеет в оверлей диаграммы экст-джиэса выводить поверх карты?)

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

openlayers позволяет агрегацию делать

эх, мичты сбываются)

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

даже мне приходится ковыряя код, спрашивать дополнительно)

так что пора строить интеграторскую контору))))

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

ну хз)

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

уже серьезный шаг вперед

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

и чем дальше вкапывался - тем меньше стал понимать как это все описать)))

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

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

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

а то механизм то мощный и нужный

а понимание слабое

discovery держится на job'ах

job -- низкоуровневое понятие

некая хрень с расписанием

репорт к джобу как относится - что кого запускает?

как я понял - результат джоба отдается репорту

а тот уже обрабатывает его(или просто кладет в базу)

report -- детали реализации

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

он необязателен

просто код так лучше читается

ну и разные job'ы могут использовать один и тот же report

но механика как я описал?

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

class InterfaceDiscoveryJob(MODiscoveryJob):

name = "interface_discovery"

map_task = "get_interfaces"

map_task

да