Описание

Миграция создаёт в AuP 2.10 устройства и аккаунты, присутствующие в AuP 1.4, пересоздает все связки и пишет дополнительную информацию (additional_info).
Далее вся информация сортируется по additional_info и группируется в несколько цепочек внутри одного потока.
Каждый пайплайн содержит комплексные узлы BLF и SIP, а также два дополнительных узла с общими и специфическими параметрами.

  1. Если устройства прописались в 2.10 по иному пути, например, через LLDP без интеграции, то они не войдут в поток. Мигратор посчитает, что устройство или аккаунт были добавлены в 2.10 ранее, и они уже имеют конфигурации, добавленные администратором. А раз так, то миграция устаревших настроек из 1.4 не требуется.
    Поэтому в новый поток уходят только вновь загруженные объекты и параметры. Впрочем, администратор сможет включить их в поток вручную позднее.

  2. Если миграция была аварийно прервана, то устройства и аккаунты, которые уже были добавлены, так и останутся в системе, но не будут включены в поток. Поток строится на BLF, поэтому добавленные устройства можно будет включить позднее.

  3. Миграцию ни в коем случае нельзя прерывать. Если кажется, что она работает слишком долго — пусть продолжает работать.
    Единожды прерванная миграция уже не построит полноценного потока и администратору придётся собирать его из отдельных импортированных устройств и аккаунтов.
  4. Миграция должна быть первичной операцией при настройке AuP 2.10 рядом с AuP 1.4. Если на AuP 2.10 были аккаунты/устройства, то при миграции они не обновятся, так как миграция не распространяется на ранее созданные устройства и аккаунты.

Логика работы интеграции:

Поток формируется с использованием простой эвристики, может быть от одной до трёх:

Все цепочки содержат четыре узла конфигуратора [BLF complex node], [SIP complex node], [Common] и [SIP static params]:

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

Вторая цепочка содержит только базовые параметры, достаточные для настройки SIP complex node, но второстепенные общие Common параметры или отсутствуют, или присутствуют у менее чем трети доступных устройств, а потому проигнорированы.

Третья цепочка имеет деактивированный узел Common, не содержащий параметров. При этом узел выбора устройств содержит идентификаторы всех устройств, которые имели уникальные свойства и не были включены ни в первую, ни во вторую цепочку.


Процедура миграции 1.4 → 2.10

Заходим внутрь контейнера:

docker exec -it autoprovision-stable-core-1 bash

Запускаем оболочку Elixir:

./ecss_aup_core remote

Рекомендуется запускать миграцию данных в синхронном режиме, для отслеживания прогресса и возникающих проблем. Однако, при таком запуске консоль будет заблокирована до окончания выполнения и ее придется держать открытой. Асинхронный же запрос создаст фоновую задачу.

Команда для синхронного запуска (следует указать актуальный хост размещения ecss-autoprovision 1.4, порт, актуальные учётные данные и размер request_chunk_size (количество объектов обрабатываемых за раз, по умолчанию = 4)):

data = %CoR.Data{
  assigns: %{
    data: %{
      payload: %{
        host: "http://10.24.0.101:1350/",
        login: "root",
        password: "ecss-autoprovision",
        default_ttl: 480_000,
        request_chunk_size: 4,
        chunk_size: 20
      }
    },
  },
  private: %{}
}

EcssAupCore.CoR.AupLegacy.Action.Migrate.call(data, [])

Команда для асинхронного запуска:

payload = %{
      host: "http://10.24.0.101:1350/",
      login: "root",
      password: "ecss-autoprovision",
      default_ttl: 480_000,
      request_chunk_size: 4,
      chunk_size: 20
}
EcssAupCore.Subscriber.request("/ecss_aup_core/request/aup_legacy/migrate", %{payload: payload}, ttl: 180_000_000)

Ожидаем завершения миграции.

Проверить количество устройств можно командой:

import Ecto.Query
EcssAupDb.Models.Device |>
Ecto.Query.select([a], count(a.uuid)) |>
EcssAupDb.Repo.one()