nocproject.org

ку

ку-ку

_4ePTeHok, опаньки

ты тут или мимо проходил?

zi_home, чем мучать надумал?)

_4ePTeHok, ты поломал когда sup720 закоммитил

_4ePTeHok, при апдейте трейс

Tried to save duplicate unique keys (E11000 duplicate key error index: noc.noc.objectmodels.$name_1 dup key: { : "Cisco | 7600 | RSP720-3CXL-GE" })

не только у меня

э

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

момент

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

_4ePTeHok, а он локальный разве, а не из репо приезжает?

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

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

на чистую прошло

чисти локальный манифест - должно проехать

а где он

./local/collections/inv/

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

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

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

_4ePTeHok, ок, вроде побежало. а еще спросить хотел

смотри

есть ASR9001

у нее два слота под МРА и несколько портов прямо на шасси

она их отдает вот так

МРА0 , sfp, sfp, sfp,... MPA1, sfp, sfp, sfp... Virtual module, sfp, sfp, sfp

Virtual module фактически и есть шасси

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

ну там надо тогда порядок просто поменять

0/0/0

0/0/0/0

0/0/0/1

...

0/0/1

0/0/1/0

0/0/1/1

...

0/0/2

0/0/2/0

...

виртуал модуле тут - 0\0\2?

да

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

NAME: "module 0/0/2", DESCR: "ASR 9000 Virtual Module"

PID: A9K-MODULEv, VID: N/A, SN: N/A

нет

он всегда с этим номером

ну тогда и пофиг

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

я не знаю какой workaround лучше

опять builtin модули бы пригодились

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

а в модельки чассиса - дырки

в модельке есть дырки

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

шасси - трансиверы, модули - трансиверы

блин

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

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

о как

_4ePTeHok, смотри http://pastebin.com/fNBzha4i

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

он тип для PSU не может определить

а он же и не нужен

там тип надо вообще упразднить

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

да, я знаю, просто пока еще не упразднено

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

_4ePTeHok, не допилишь скрипт? а то его dvolodin писал, а ты на Cisco.IOS скрипте уже наблатыкался

там RP съемное?

в данном шасси нет

это железка такая, в одной коробке собрали RP и LC от большой железки

т е кроме MPA и SFP - все builtin?

да, абсолютно так

ну еще FAN и PWR съемные

но это не проблема

мм. ну так может и не снимать их тогда

в смысле?

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

как будто есть выбор

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

ну смотри - ловим шасси

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

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

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

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

{'builtin': False,

'description': 'ASR 9000 Virtual Module',

'number': '0',

'part_no': ['A9K-MODULEv'],

'revision': 'N/A',

'serial': 'N/A',

'type': 'MOD',

'vendor': 'CISCO'},

тип стереть

номер есть

и создать пустую модель

с типом шасси

уверен что на 9010 скажем не будет такого же виртуального модуля с тем же пидом?)

нет, там все реальное

у меня есть 9010, там нет виртуальных модулей

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

хотя тут тоже не ясно. если буилтин - то в чо встроен то, в шасси или в карту)

родителя то нету

_4ePTeHok, формально он встроен в линейную карту, которая встроена в шасси

то есть CHASSIS > LC (builtin) > MPA0 + MPA1 + Virt(builtin)

надо код по этому поводу глянуть

как вообще буилтин там обрабатывается(если обрабатывается)

на самом деле это не первый раз

у циски повсеместно builtin модули отдаются в инвентори

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

у 4924 похожая фигня

NAME: "Switch System", DESCR: "Cisco Systems, Inc. ME-4924-10GE 1 slot switch "

PID: , VID: , SN: FOX1237H0UC

NAME: "Linecard(slot 1)", DESCR: "1000BaseX (SFP), 10GE (X2) Supervisor with 24+4 1000BaseX SFP ports and 2 10GE X2 ports"

PID: ME-4924-10GE , VID: V04 , SN: FOX1237H0UC

да я знаю, что такое много где

счас, погоди, подправлю типы

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

ок

всякие pfc, dfc, msfc на 7600 тоже такие по сути

э не

оно съемное

в отличии от

спорный вопрос

с помощью отвертки оно все съемное

вопрос лишь в бухгалтерии

наверное соглашусь, один builtin отличается от другого

_4ePTeHok, модельку для блоков питания делаю, не знаешь как такой раъем может называться http://shop.nag.ru/uploads/catalog_item_image/9839/asr-9001_5.jpg

не..

zi_home, http://pastebin.com/Y8DwjJe7 проверь, так должно распарсить БП и РП

пршел смотреть про буилтин

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

т е предлагаешь отсечь типы на корню?)

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

для разных типов

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

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

У кого DXS-3600-32S там профиль DxS_Cisco_CLI вообще не подходит, нодо новый писать. Кто уже пробовал?

надо думать, но типы надо убирать

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

_4ePTeHok, напомни как дифф применить, команду не найду

patch же

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

ааа

root@noc:/opt/noc # hg patch /home/iz/inv.diff

abort: uncommitted changes

без hg)

чего-то он долго патчит

_4ePTeHok, а ты это закоммитить можешь?

- if self.has_uuid and "uuid" not in attrs and not o.uuid:

+ if self.has_uuid and not attrs.get("uuid") and not o.uuid:

вроде работает

и это NOC-1292

да могу) вопрос надо ли)

работает ведь

есть баг, есть исправление

почему нет

ну ок)

_4ePTeHok, что-то я не то делаю

root@noc:/opt/noc # patch /home/iz/inv.diff

и висит

patch < mods.diff

да, побежало, маны надо читать

отловило все?

комиттить?

_4ePTeHok, да, отловила все

ну ок

уезало в репо

_4ePTeHok, а что с остальными патчами делать? uuid

NOC-1292 тоже висит

uuid уже в репо

остальное на очереди

dvolodin, закоммить если не занят NOC-1292

я делаю уже

zi_home, в репо.

ну у тебя и очереди

за дефицитом

ну у меня рабочий день сегодня)

о как

чот моделек мало наделали

или не делитесь просто)

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

_4ePTeHok, чего там с builtin

ничего)

оно почти нигде не учитывается

будем пинать

dvolodin, Дима, а расскажи как в инвентори быть с модульными нексусами, те что 5000 с выносными блоками

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

и не стек это в данном случае

почему нельзя

выдавай его как шасси

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

на самом деле оно абсолютно без разницы

без всяких лишних интерфейсов?

без

окай

SRX тоже в кластер собираются

и нормально обрабатываются

просто get_inventory возвращает несколько CHASSIS

расскажи немного про джобы. Точнее интересует кто их запускает. Вот скажем inv\jobs - там noc-discovery их по lib\scheduler запускает, так?

scheduler их запускает

а чем тогда noc-discovery занят?

крутит этот scheduler

scheduler -- это абстракция :)

про builtin еще спроси

scheduler запускает job'ы

а вот джобы в ipam / dns?

какой демон за них ответственен

то, что в */jobs запускает другой scheduler

из noc-scheduler

хм.

что тебя смущает?

не могу понять иерархию)

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

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

и да, там в https://bitbucket.org/nocproject/noc/commits/9d373aaf969097b552d8eb6dd85b70feca9e5050 неверная моделька была, пришлось переименовывать. Т е пид был верный - а имя файла и имя модели - нет. При обновлении надо будет из локального манифеста грохнуть старую модельку...

dvolodin, а что нок сделает если скрипт вернет два шасси с одним номером

лучше так не делать)

не грохнется, ему пофиг

мне надо как-то sfp в шасси вставить

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

там одна строка

э, стоп

_4ePTeHok, мы же обсуждали. виртуальный модуль

у тебя же виртуал та

он как мод отдавался

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

как бы это сказать

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

а втыкает он в него, а не в шасси

dvolodin, как быть с builtin?

chassis - virtual MOD - XCVR

даже кошерней chssis - LC (builtin) - virt mod (builtin) - xcrv

LC у тебя же не отдается, там RP

то есть в шасси стоит RSP и LC, на LC есть два раъема под МРА и еще один модуль встроен, и на нем 4 дырки sfp+

_4ePTeHok, отдается

NAME: "module 0/0/CPU0", DESCR: "ASR 9001, Modular Line Card"

PID: ASR9001-LC, VID: V01 , SN: FOC1740N48W

сразу после РП

a пропустил.

а в конце списка идет шасси

то есть есть шасси

в нем торчит

RSP и LC

на LC

MPA0-slot, MPA1-slot, virt module

virtual module представляет из себя 4 sfp+ дырки

можно представить ка несъемный уже распаяный МРА

у них и нумерация соответствующая

0/0/0 (MPA0), 0/0/1 (MPA1), 0/0/2 (VIRT)

я не знаю что еще рассказать

а 0/0 это линейная карта

dvolodin, помогай, без тебя не справимся

бррр

вы про какую платформу вообще?

ASR 9001

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

dvolodin, вот что возвращает скрипт инвентори сейчас

http://pastebin.com/r2DtT472

в принципе, в connection rules можно ограничить scope конкретным шасси

connection rule Cisco | ASR9k, сейчас втыкает все кроме последних четырех трансиверов. он пытается их воткнуть в МРА последнюю а не в шасси

dvolodin, я же говорю, без тебя не справимся

погоди, вкурить надо

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

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

странный у вас отдых :)

накрутил я, короче, франкенштейна :)

дома создаются

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

осталось по улицам разнести

вот лучше отвлекитесь

посмотрие OSM

по моим данным, там в XML есть привязка координат и кода КЛАДР для дома

посмотрите, как ее выдрать

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