Ну, и при попытке ченить сделать - дико лагает, да?

Конечно

Причем зависит от клиента

От мощностей

экстремальная магия которая находит в логах работы дискавери ошибку RPC

Конечно

Ну так неюзабельно жи

Причем зависит от клиента

Ессно

Ну так неюзабельно жи

Именно

#script

И чем больше карта, тем хуже лаги

Именно

Ну так я и предлагаю облегчить! )

Ну так я и предлагаю облегчить! )

Вон 2 мин в гугле показали мне js gpgpu

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

На js есть же куча игр и не особо тормозит

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

Нет конечно, тормозит именно отрисовка

uptime is 11 years, 40 weeks, 4 days, 4 hours, 37 minutes

Беги оттуда

А Цпу нагруженно?

Беги оттуда

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

А Цпу нагруженно?

Хз, ушел из за компа

Но это не запросы

Может либа js такая тормозная

Но это не запросы

Во первых, ткни ф12 и убедись, во вторых, даже 10к запросов не будут минуты выполняться

Может либа js такая тормозная

Ну видимо

экстремальная магия которая находит в логах работы дискавери ошибку RPC

поподробнее?

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

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

хотя говорят это не самый лучшей способ

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

sysfaray opened merge request at / noc: WIP: Add Controller TTronics Profile

merge request opened by sysfaray

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

А как оно было?

У меня никак. Нашёл много дерьма. Главное быстро

https://pp.userapi.com/c841122/v841122366/5ebf2/FIiVP4DKRu0.jpg

sysfaray opened merge request at / noc: WIP: Add Controller TTronics Profile

merge request opened by sysfaray

dv opened merge request at / noc: WIP: IPAM NG

merge request opened by dv

unknown models export поломан

а ты думал

?

sysfaray opened merge request at / noc: WIP: Add Controller Electron Profile

merge request opened by sysfaray

короче, я что-то страшное сделал

sysfaray opened merge request at / noc: WIP: Add Controller TTronics Profile

merge request opened by sysfaray

у нас ipam живет в iframe

и самое слабое место у него -- формы

я умудрился оставить навигацию HTML'ную

а формы переключаются на Ext

По IPAM план такой

1. Добавить профили префиксов (уже сделал)

По IPAM план такой

Во, самое главное :)

sysfaray opened merge request at / noc: WIP: Add Controller Electron Profile

merge request opened by sysfaray

у меня план поспать )

2. Переделать форму для создания и редактирования префиксов

не знаю как у вкас

3. Профиль и форма для адреса

автодискавери?

при этом ip/ipam/view.py худеет раза в два

4. переводим остальные формы на Ext

при этом ip/ipam/view.py худеет раза в два

за счёт чего ?

в итоге по части ввода и редактирования данных IPAM у нас становится похож на все остальное, появляются профили VRF

@freeseacher за счет классов django forms и прыгалок вокруг них, все это уходит в ExtModelApplication обычные (ip.prefix и ip.address)

@dvolodin Дим, пока ты тут, перебью.. А можно субкласс для Ping failed по rtt сделать? Чтобы понятно было чем вызвана авария

Или это не входит в планы?

Ilya не понимаю, про что ты

дальше мы эту ветку сливаем

и смотрим регрессии

вторая ветка пойдет -- VRF уедет как один из видов VPN

потом поедет ветка с discovery

Ilya не понимаю, про что ты

Аварии открываются с классом ping failed по rtt. И непонятно, то ли железка отвалилась по доступу, то ли связь хреновая с ней. Недавно напоролись после инсталляции n77 на высокие задержки (pe-n77 напрямую подключены инбоунд менеджмент) и аварий море было

Пока еще не решил, стоит ли или нет переносить данные ipam в mongo

в случае с discovery там постоянно нужно будет менять отметку last seen

постоянный update в базу

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

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

после ip discovery будет еще object discovery

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

либо из arp-кешей, либо пингом

затем, если профиль адреса предусматривает поиск объекта -- будут подбираться пароли, опознаваться платформа, выдираться get_chassis_id и создаваться новый MO

@dvolodin не пиши тут. лучше в форум.

либо из arp-кешей, либо пингом

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

пингом с пингера

настраиваться будет

там все вокруг workflow пляшет

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

chassis id совпадут

а если мы на эту железку уже заходили -- интерфейсы к адресам в interface discovery привяжутся

сейчас привязка адреса к mo - ручная

будет автоматом

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

от профиля зависит

если профиль префикса разрешает ip discovery с интерфейсов -- то будут автоматом создаваться адреса, если их видели на интерфейсах

если разрешен ip discovery с ping -- потихоньку с пингеров прилетать будут

если из arp -кеша -- то с железки

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

как мы любим.

если разрешен ip discovery с ping -- потихоньку с пингеров прилетать будут

вот тут вопрос мне не понятен. Как он будет понимать что пингать?

дима думаю эту логику в доку всё равно положит

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

дима думаю эту логику в доку всё равно положит

Я себе всё сохраняю)

вот по ним и будет проходить

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

Догадался. А если у пингера нету доступа в ту сеть?

сам дурак

NOC-то тут при чем