удаляторы

или удабляторы

или удабляторы

Удаление работает не так, как все одидают

в этом случае необходимо искать трейсы в консоли браузера или в логах ВЕБа

да, действительно, ступил

Удаление работает не так, как все одидают

что поделать, вот не будет постгреса.... тогда вообще будет ад

EXCEPTION: <type 'exceptions.AttributeError'> 'int' object has no attribute 'id' и т.д. и т.п.

буду переустанавливать :(

буду переустанавливать :(

зачем?

что поделать, вот не будет постгреса.... тогда вообще будет ад

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

зачем?

Потому что все равно пустая инсталляция, а уже куча всего поломато

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

это невозможно. ПРи наличии rw доступа к базе

это невозможно. ПРи наличии rw доступа к базе

Я имею в виду а) кнопку в MO, б) wipe

Я имею в виду а) кнопку в MO, б) wipe

@EKbfh не выдержит

и потеряет смысл жизни

нельзя так

что поделать, вот не будет постгреса.... тогда вообще будет ад

Во славу сатане

Во славу сатане

ну вот, стоило только намекнуть

посмотрите VPN

какие там еще идеи будут

как их discover'ить

и потеряет смысл жизни

А делете в МО делает анменеджд?

и я vlan'ами займусь

а потом -- префиксами и адресами

@aversant А посоветуй тогда, как разрулить кейс: 1) Добавляем коммутатор, например, с IP 10.1.1.1 и name='10.1.1.1' 2) Через 2 недели он сдох. В своей БД мы его перемещаем в "сегмент" "ремонт", или "кладбище", удаляем ему IP. Что сделать в ноке? Снять 'managed' и переименовать? 3.а) Через месяц ставим другой коммутатор, назначаем ему IP '10.1.1.1'. Не будет ли коллизий, поскольку уже был объект, названный '10.1.1.1'? 3.б) Через месяц снятый коммутатор приезжает из ремонта. Нужно его как-то найти, но как, если мы его уже переименовали? Например, мы в своей БД однозначно идентифицируем по маку, но в ноке нет отдельного поля для мака. Есть какие-нибудь бестпрактис? (Если только переименовывать железку при "удалении" в её мак, но тогда привязки к ипаму отпадают).

@aversant А посоветуй тогда, как разрулить кейс: 1) Добавляем коммутатор, например, с IP 10.1.1.1 и name='10.1.1.1' 2) Через 2 недели он сдох. В своей БД мы его перемещаем в "сегмент" "ремонт", или "кладбище", удаляем ему IP. Что сделать в ноке? Снять 'managed' и переименовать? 3.а) Через месяц ставим другой коммутатор, назначаем ему IP '10.1.1.1'. Не будет ли коллизий, поскольку уже был объект, названный '10.1.1.1'? 3.б) Через месяц снятый коммутатор приезжает из ремонта. Нужно его как-то найти, но как, если мы его уже переименовали? Например, мы в своей БД однозначно идентифицируем по маку, но в ноке нет отдельного поля для мака. Есть какие-нибудь бестпрактис? (Если только переименовывать железку при "удалении" в её мак, но тогда привязки к ипаму отпадают).

а из своей системы как-то можно выгружать объекты?

да

как угодно, в принципе

всё самописное

посмотрите VPN

Дим, мне не совсем понятна идея с RD>MO>export>цель

Цель - тот, кто импортит

А ты для заглушки сам-себя указал?

И ещё, можешь правее от "цель" добавить destination mo name?

да

вообще, в НОКе есть механизм выгрузки объектов из внешней системы. можно воспользоваться. По логике получается так. Если коммутатор сняли - то делать его unmanaged и переименовывать во что-нибудь вроде deleted и помещать в сегмент-отстойник, чтобы глаза на карте не мозолил

Это очень простой пример из 2х объектов, а если их 30-40?

желательно это через выгрузку автоматизировать. Чтобы голову не ломать

Дим, мне не совсем понятна идея с RD>MO>export>цель

@dvolodin

вообще, в НОКе есть механизм выгрузки объектов из внешней системы. можно воспользоваться. По логике получается так. Если коммутатор сняли - то делать его unmanaged и переименовывать во что-нибудь вроде deleted и помещать в сегмент-отстойник, чтобы глаза на карте не мозолил

» вообще, в НОКе есть механизм выгрузки объектов из внешней системы. можно воспользоваться. Это не очень, потому что в 2017г хочется риалтайма :) Ну там, добавили в одном месте - оно по api разлетелось везде. А не раз в сутки сверять базы

ну, кто же мешает пустить крон раз в 15 минут

вообще, в НОКе есть механизм выгрузки объектов из внешней системы. можно воспользоваться. По логике получается так. Если коммутатор сняли - то делать его unmanaged и переименовывать во что-нибудь вроде deleted и помещать в сегмент-отстойник, чтобы глаза на карте не мозолил

» По логике получается так. Если коммутатор сняли - то делать его unmanaged и переименовывать во что-нибудь вроде deleted и помещать в сегмент-отстойник, чтобы глаза на карте не мозолил Но. Если вдруг мы потом его заново добавим? В БД нока ведь уже будет объект с такими же интерфейсами-серийниками-маками Или unmanaged все эти проблемы решает?

ну, кто же мешает пустить крон раз в 15 минут

Ну это же костыль какой-то из начала 2000-х)

Ну это же костыль какой-то из начала 2000-х)

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

» По логике получается так. Если коммутатор сняли - то делать его unmanaged и переименовывать во что-нибудь вроде deleted и помещать в сегмент-отстойник, чтобы глаза на карте не мозолил Но. Если вдруг мы потом его заново добавим? В БД нока ведь уже будет объект с такими же интерфейсами-серийниками-маками Или unmanaged все эти проблемы решает?

и что обозначает такими-же интерфейсами? При переводе в unmanaged чистится DiscoveryID кэш. По логике, старый объект должен стать Managed и продолжить работать

раз его вернули

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

А что будет с объектом, который раньше был, а потом перестал быть, в выгрузках? Он сам станет unmanaged в ноке?

тут вопро состоит в том, что есть ID объекта

тут вопро состоит в том, что есть ID объекта

Вот да, я об этом выше и спрашивал, по какому признаку, кроме name, можно было бы однозначно идентифицировать

А что будет с объектом, который раньше был, а потом перестал быть, в выгрузках? Он сам станет unmanaged в ноке?

что в адаптере выгрузки написано, то и будет

что в адаптере выгрузки написано, то и будет

а, понял

если он исчез, то будет unmanaged

например.

А если такая ситуация: - объект 1.1.1.1 , ModelA, 48 интерфейсов - сняли, сделали unmanaged - затем вернули из unmanaged с адресом-именем 1.1.1.1, но при этом это уже ModelB, 24 интерфейса

это нормальная ситуация, или будет жопа?

А если такая ситуация: - объект 1.1.1.1 , ModelA, 48 интерфейсов - сняли, сделали unmanaged - затем вернули из unmanaged с адресом-именем 1.1.1.1, но при этом это уже ModelB, 24 интерфейса

что обозначает вернули ? у объектов есть ID

в базе

всё

что обозначает вернули ? у объектов есть ID

Ткнули ему опять галку managed

Ткнули ему опять галку managed

он опросится и ему будут новые интерфейсы. Старые почистятся

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

отлично!

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

благодарю за ликбез :)

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

мало, вдруг какие баги ещё всплывут.

@wingz а шина то какая?

ERROR: S client not available

шина?

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

Esb какой нить

шина?

интеграционная шина. Для интеграции разных ПО, чтобы они могли обмениваться данными.

как раз для реализации realtime обмена данными

Да в теории - что угодно

rest - отлично подходит

с билингом по pl/sql, с забиксом по rest общаемся

rest - отлично подходит

плохо подходит. Для таких задач.

Это не разлетелись :)

Но так можно да

Но придется хранить два ойди

В первой системе и во встречной

Вопрос по метрикам: - настроено следующее

В Box и Periodic метрики включены

в логах дискавери вох на устройстве вижу следующее

Так низя

Пинг надо убрать

Вопрос - почему и где что не настроил?

Я про Object metrics и Interface metrics

Пинг надо убрать

Убрал, проверяю.

В переодик Дискавери опрос метрик включен?

В переодик Дискавери опрос метрик включен?

Да

тоже самое object и interface metrics не настроены. Что еще может ему требоваться?

Это не разлетелись :)

Ну, я образно :)

Господа, а дока на Workflow есть?

Как с этим разобраться кроме метода тыка?

Пока дока на питоне