nocproject.org

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

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

но, возможно, стоит сделать сервис для бронирования

почему?

ограничения целостности сработают

один нажал add first free и ему выдало номер 111, он заполняет данные, потом второй жмет кнопку, ему выдается тот же 111, потому что в базу он еще не занесен, первый сохраняет, оно добавляется в базу, второй сохраняет и данные перезаписываются

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

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

Дима, по поводу вчерашнего вопроса есть идеи?

"а как мы будем коррелировать интерфейсы из get_interfaces и из get_inventory? применимо к серверам. ну отдам я номер(bus) состыкуется оно с NIC1 например, а дальше? В ОС то оно eth1 например"

"из скрипта я могу дернуть logical_name = eth1, но ее некуда отдавать и опять же, смотри - мы дергаем физические карты. Есть двухпортовая сетевка к примеру(комбинированное устройство), как объект - одна позиция, серийник у сетевок - мак, но там их два, а в моде

ли у нас серийник однозначен.

Давай сделаем серийники list-ом, как prod_no?"

"и добавим в модель logical_name, чтобы коррелировать потом можно было"

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

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

можно возвращать меньший из всех

min(....)

internal_name у тебя заработал?

я еще не дошел) забиваю вендоров, коннекторы и начинаю модельку рисовать

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

я при проходе нового блока(девайса системы) проверяю - есть ли уже в objects на той же PCI шине устройство(совпадение prod_no и number) и если есть поднимаю флаг complex_device. Соответственно пока реакцию на поднятый флаг сделал - пропуск, но можно скажем добавлять ч

то то в уже существующий объект(например [eth1, eth2])

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

раньше выдается то, что по шине раньше

т е pci@0000:04.0 первее pci@0000:04.1

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

pci@0000:04.0

это примерно -- шина 0000

устройство 04

ну и дальше на плате?

pci@0000:0a:00.0 вот так в реальности

это к примеру видеокарта

'pci@0000:0a:00.1'

а это аудиоконтроллер хдми на ней же

вот за точкой по моим наблюдениям всегда то, что на этой же плате(чипе)

что такое вообще pci@xxxxxxxxxx

bus

All devices have at least 1 function, function #0. There are 8 possible functions per device, numbered 0-7. Any device that has more than 1 function is (hey clever!) called a multi-function device. Multi-function devices, such as a combination modem+soundcard will usually have 2 uniquely addressable functions, numbered 0 and 1.

угу, так и есть

хочу терминологию понять

итого .0 -- это function 0, которая есть всегда

http://www.waste.org/~winkles/hardware/pci.htm

ну мы же не функции дергаем, нам надо только device. Потому можно смело резать все что за точкой

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

для сетевок - это скажем имя интерфейса в системе

ну да

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

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

http://lwn.net/images/pdf/LDD3/ch12.pdf

Each PCI peripheral is identified by a bus number, a device number, and a function number.

The PCI specification permits a single system to host up to 256 buses, but because 256 buses are not sufficient for many large systems, Linux now supports PCI domains. Each PCI domain can host up to 256 buses. Each bus hosts up to 32 devices, and each device can be a multifunction board (such as an audio device with an accompanying CD-ROM drive) with a maximum of eight functions. Therefore, each function can be identified at hardware level by a 16-

address, or key

одни пишут 8, другие 16

что значит 16-address, при 8-function)

pci@0000:0a:00.0

тогда тут у нас 0000 - bus, 0 - function

а что 0a и что 00 ?

domain/device?

мм..нене

или на плате bridge

pci

0000 - домен

256 - FFh же

0a - bus, 00 - device

0 - func

'pci@0000:12:0d.6' вот например Host controller

первые 4 байта у меня всегда нули

ой, ну домен короче

sck nrk

'pci@0000:18:04.0' 'pci@0000:18:10.0' - два разных 'PEX 8664 64-lane, 16-Port PCI Express Gen 2 (5.0 GT/s) Switch'

на одной шине, два девайса с 0 функцией

ну правильно

0-я функция у него -- входная

угу, я про то что домен - первая четверка

ok

у usb схожая адресация

там еще про диски будет подобное

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

без рейдов если)

с ними вообще непонятно как быть.

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

угу, то есть зависимости тащить...

ну собственно с нвидией оно уже так0

=)

метод сбора потом можно и поменять

я думаю что просто детектить есть ли рейд в устройствах, и в зависимости от этого делать try:/except: print "Please install blabla software for support your device"

повендорно

хотя бы

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

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

по серийникам-то?

давай брать их с funciton 0

не, это ясно

я про интерфейсы с гет_интерфейсес

eth0 и т д

а вот это я думаю

Bus : 0x16

Device : 0x00

Domain : 0x0000

Bus Id : 0000:16:00.0

да вот подтверждение

это и для сетевых железок нужно

отображение connection на имя интерфейса

у сетевых проще. Там name коррелируется с interface

у сервачных там корреляции без доп. переменных вообще нет

может там руками/

?

а я вот кстати не смотрел что отдает линуксовый get_interfaces)

руками не удобно

я говорю - я могу снять в get_inventory имя интерфейса в системе

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

чтобы модель сожрала

гы, а get_interfaces никто и не писал для линукса.

печалько.

давай сделаем для get_inventory параметр {function:logical_descriptor}

тогда оно ляжет как {0:eth1} {1:eth2}

funcion - это из bus, тот последний октет за точкой

в итоге мы знаем bus device, function, logical_descriptor, и сможем соотнести какие интерфейсы как в системе обозваны и полный путь bus до них.

а по полному bus - мы знаем какая дырка NIC1 или NIC2

а если там 4 порта?

будет 2:eth3

и т д

полный bus все равно будет разным

тогда по логике вещей должно быть что-то вроде bus id -> interface name

на выходе

да

проблема в другом

для сетевого железа другой подход потребуется

дык там в name уже имя интерфейса

тут еще вопрос как приземлить на мамку эти вот сетевки, встроенные в нее.

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

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

не...конкретной физической дырки

имя то у нас в get_interfaces еще

вместе с линком

а, ты connection в терминологии инвентори, тогда да

вот как эту привязку без пользовательских функций сделать, не знаю

dvolodin, еще по блейдам загвоздка. По идее там должен быть контейнер на верхнем уровне иерархии(chassis), но оно не активное ни капли бывает - просто как железный ящик с БП и FAN, но при этом с блейда вытягивается информация про БП и FAN.

т е блейд допустим пол-ящика

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

это как это оно не активное

активность этого самого пассивного бэкплейна на HP блядьцентр 7000 мне в свое время изрядно крови попортила

ну вот так, шасси для HP ProLiant SL390s G7 не имеет никакого отражения в ОС блейдов

точнее блейды отдают свое шасси

а, ты про это

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

и уже из них видят БП и FAN общие для обоих половинок

а вот внешний ящик - ни где не фигурирует

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

оно вон как http://www.saronit.ru/catalog/hp-proliant-sl390s-g7/hp-proliant-sl390s-g7-x5672-626447-b21

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

руками*

а ящики там такие - http://shopping1.hp.com/is-bin/INTERSHOP.enfinity/WFS/WW-USSMBPublicStore-Site/en_US/-/USD/ViewStandardCatalog-Browse?CatalogCategoryID=YVsQ7EN6wesAAAEuJQoVgV7T

и не надо

direction o

и все

э, не понял

блейд -- тот же модуль

это понятно. Я про то, что вот этот вот ящик ты не вытянешь в get_inventory

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

ну не вытащишь

что блейд в воздухе висеть не может

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

из lost&found

мм..а как тогда с БП правильно обойтись?

физически они в этот ящик втыкаются

но их видно с каждого блейда

в ящике они

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

а видать в ящик

кидать*

ну да

вообще они через management все отдают

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

а оно надо кому-нибудь вообще?

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

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

dvolodin, там нет на ящике никакого managment

это все уже на блейдах

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

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

connection rule кстати не дает выбрать пустым.

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

на BLc7000 есть

http://xkcd.ru/1296/

дык это, можно модели вручную цеплять? или делать ящик контейнером(Group)

нет

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

там еще есть вариант, когда лезвие занимает 2 слота

ну модель то я сделаю

вопрос в том, как оно потом сцепится

connecton type

а для чего в коннекшенах model data?

на всякий случай

так, у нас там 2 ноды, R и L, коннекшены тогда надо тоже делать 2 типа

чтобы левый в правую нельзя было воткнуть

они несовместимы?

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

ok

тогда разные, да

HP | ProLiant s6500 Chassis Right Node

типа того

а LGA-1366 - это инлета изобретение?

Intel | LGA-1366 делать?

или по категориям = CPU | LGA-1366

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

они их не стандартизируют

так что второй вариант

второй, да

ARM'ы, скажем, разные вендоры могут делать

пусть будет CPU | *, RAM | *

я переделываю сейчас способ синхронизации базы из json

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

я вот еще чего подумал. Для устройств, что на мамке, сделал Connection type = MBoard | Internal , которым они цепляются к MB

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

устройства на мамке разные

нужны pci* разъемы

и у тех же блейдов меззанины

мм..

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

RAM | DIMM 240-pin

при этом схема их наименования = PROC 2 DIMM 1F

каклй им делать name?

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

мне удобнее видеть сразу физический разъем proc1_dimm_1F

internal_name = 1:1F

а про мамку - мы же не знаем, pci оно или pcie например

ну и что

а для физических карт - будет именно различатся

ты же connection type вообще не выдаешь в get_inventory

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

да

для встроенных разъема нет

физически

нет

но они и builtin

хех, ну сейчас = нет

потому что их не определить

потому и сделал затычку MB | Internal

мы builtin'ы определяем по bus id?

это единственный способ

вот только как это провернуть

в объекте internal name - в коннекшенах

а нам надо чтобы оно объект пометило втроенным, еще и родителя указало

о

кстати

а если его нет нигде в internal_name, то оно вполне себе builtin

а?

а как дырки соотносить потом?

оно же тоже по bus соотносится

дырки на мамке сразу

это понятно, как их привязывать

что nic2 - это скажем интеловский чип, а не бродком

оба встроенных

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

никак

не должно

видно будет разъемы его

не очень хорошо, видеть бы чипы в итоге в свойствах

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

а объект тогда с таким bus - приклеивать к родителю

ну да

вот только объект может от другой железки болтаться)

с таким же bus

или не?

PCI-e | rev 2.0 | x16 нормуль так обзывать?)

ну да

а

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

может так

PCIe | 2.0 | x16

?

да как скажешь

а можно в inv.inv позволить редактировать имена объектов?

_4ePTeHok: уже можно

во вкладке data кликни два раза на name

и редактируй

эм, давно? у меня не работает еще)

вчера вроде

ага, обновляться надо

это вообще полезно иногда

только не когда пол-дня модельки клепал в built_in)

Скоро признака is_builtin вообще не будет

:)

а как определять что останется после апдейта, а что снесет?)

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

нет

манифесты будут

ох ё. страшное слово

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

скажи, а airflow у нас ко всем объектам добавляется где тепловой интерфейс есть?

вот скажем CPU/GPU

или это только шасси

на шасси имеет смысл

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

из стойки

а у нас можно реализовать совместимость коннекшенов? вот скажем PCIe 2.1 вставить в PCIe 2.0

и плиз, объесни доходчиво, какую роль играют context записи в connection rules

да

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

или через cgroup

а второй вопрос?

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

его в логе видно на каждый найденый модуль

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

и держится там либо пока не перепишется, либо пока не сработает reset context для него

эм. т е общая логика работы рула такая - берется устройство, для него формируется контекст(читай дергается намбер в xxx), а дальше сам рул должен сравнить тип, и таргет номер, и воткнуть в коннекшен xxx{n}, верно?

контестов много может быть

ну да, в них переменные, по которым имя connection'а можно определить

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

d vjltkb pfgjkybk

в модели заполнил.

просто в target connecton указываешь {N}

Trying to connect #1. CPU (Ncpu=0, chassis=None, Nchassis=0, NN=1, cpu=cpu@0, N=cpu@0)

Connecting CPU cpu@0:in -> CHASSIS None:cpu@0

Failed to connect: Remote connection not found: cpu@0

хм. ну name в шассях CPU0 lf

да

это что, name должен быть равен internal_name?

нет

оно проверяет по name, если не находит, то по internal name

не работает значит

у меня интернал - как раз cpu@0

в name - cpu0

покажи модель и connection rules

http://pastebin.com/qnkm740q

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

и е придется делать общий рул для всех серверов

т е*

и кусок get_inventory с процом

scope cpu нужен вообще?

эм..

ну я для теста

ты еще gender на проце попутал

{'builtin': False,

'description': 'Intel(R) Xeon(R) CPU E5649 @ 2.53GHz',

'number': 'cpu@0',

'part_no': ['E5649'],

'serial': 'None',

'type': 'CPU',

проц - папа, на плате - мама

'vendor': 'INTEL'},

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

какая она мама

на проце - контактные площадки

да без разницы, в общем-то

ну дык где ошибся?)

полный лог discovery дай

косячок нашел

косячёк это клёво

_4ePTeHok: вытащи фикс

через час, убегаю счас..

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

один поправил, другой - нет

бывает.

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

было весело. нашли после 4 месяцев прадакшена

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

я так в Brocade SX воткнул питальник от RX. он один и тот же

а шасси совсем разные, у них свои наборы плат

e_zombie: адинэс зарабатывает веб-трансляциями. у них подводные программисты кодят на дне бассейна. это всем известно. А софт - побочный продукт, как газ при добыче нефти

Так... для живых, пользующихся FM. Врубите консоль явы, откройте вкладку алармов, посмотрите на лог HTTP запросов. Там должно идти обновление грида. Закройте вкладку алармов. У меня в фаерфоксе обновление грида никуда не пропадает. похоже на багу.