Нашёл, что команда начала готовить миграцию на Train, но это не мои ребята, особо деталей у меня нет. Но в апстрим что-то всё равно видно будет, как пойдёт.

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

приходится по кускам собирать

инфу

Апгрейд: Shipyard –> Armada и всё как обычно

Да, это у меня следующий этап.

> команда начала готовить миграцию на Train
Ты ж говорил, что апдейт между версиями не того, вы ж не новыми клаудами мигрируете?

Между мажорными версиями я вживую процесса у нас не видел. Но пишут, что готовят in-flight upgrade stein->train. Ставим политику rollingupdate pod’ам, и поехали. Но это пока в разработке, на сколько я вижу доки, репо и пайплайны.

Понятно, работы много.

Запроси публиковать.

Кстати мысль.

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

Вот этим и занимаемся. Раббит ещё потенциально. Ну и там много что ещё. Что-то деприкейтнулось. Операционка уже 18.04, там systemd-resolved, chrony, netplan, etc. Дрова новые на сетевушки.

Привет! Есть вопрос по Openstack (Stein) + Ceilometer + Gnocchi

Пробую получить cpu util по статье
https://medium.com/@berndbausch/how-i-learned-to-stop-worrying-and-love-gnocchi-aggregation-c98dfa2e20fe
или по ответу https://stackoverflow.com/questions/56216683/openstack-get-vm-cpu-util-with-stein-version

# gnocchi aggregates '(metric cpu rate:mean)' id=0203af36-f579-4e06-8a82-f4f4ccd4d487 | tail -3
| 0203af36-f579-4e06-8a82-f4f4ccd4d487/cpu/rate:mean | 2020-06-19T08:20:00+00:00 |       300.0 | 91430000000.0 |
| 0203af36-f579-4e06-8a82-f4f4ccd4d487/cpu/rate:mean | 2020-06-19T08:25:00+00:00 |       300.0 | 92510000000.0 |
+----------------------------------------------------+---------------------------+-------------+---------------+

# gnocchi aggregates '(aggregate rate:mean (metric cpu mean))' id=0203af36-f579-4e06-8a82-f4f4ccd4d487
Invalid input: 'aggregate' operation invalid for dictionary value @ data[u'operations'] (HTTP 400)

Никто не сталкивался?

Привет. Вляпался в вопрос с зависающими миграциями. Может кто-то сталкивался/видел рецепт?
Newton.
На одной из нод openstack'a случился oom. После этого перестали нормально работать миграции. В том числе и для остальных нод. Перезапуск служб не помогает. По virsh list —all вижу, что инстансы приезжают на целевую ноду, однако в openstack повисает состояние migrating, в базе nova висят указания на исходную ноду, в neutron указания migrating to.
На исходной ноде в node-compute.log болтаются сообщения вида:
Migration operation has completed
Error monitoring migration: The server has either erred or is incapable of performing the requested operation. (HTTP 500)
Live migration failed.
VM Stopped (Lifecycle Event).
После чего периодически повторяющиеся
During sync_power_state the instance has a pending task (migrating). Skip.

При этом на целевой ноде
VM Resumed (Lifecycle Event)
During the sync_power process the instance has moved from host node5 to host node2.

Значения в базе конечно поправить можно (что я и делал), но это помогает ровно до первой лайв-миграции.
Рассинхроны фактического состояния инстансов и тем, что говорит openstack ловил и раньше, но то были случайные какие-то события. Здесь же какое-то повальное влияние на все тестовые инстансы.
С продакшн инстансами, скорее всего, будет то же самое.

что сделать то хочешь?

Мне нужно получить сpu utilization истанса в процентах, для внешней системы.

вот пусть внешняя система и считает у тебя utilization, а в гноче бери cpu

Да так и придется делать.

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