Хорошо и всегда, а не когда серв нахер ни кому не нужен. Так точнее

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

правда всё это в гетерогенной инфраструктуре (xen для привата и openstack у публичных провайдеров) но работает норм

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

@TaianaGor будет жить. Поприветствуем!

@DurnayaKonechnost будет жить. Поприветствуем!

забаньте его уже

@aleksiuyel будет жить. Поприветствуем!

Sergey Kalinin будет жить. Поприветствуем!

А подскажите пожалуйста почему может игнорироваться параметр default_volume_type

OS pike

я прямо боюсь спросить, а он в конфигах есть и cinder уже его видит и может с ним работать?

А подскажите пожалуйста почему может игнорироваться параметр default_volume_type

Тут объявлен этот тип openstack volume type list --long ?

я прямо боюсь спросить, а он в конфигах есть и cinder уже его видит и может с ним работать?

уф, да в конфигах есть и работает

Тут объявлен этот тип openstack volume type list --long ?

да

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

и в flavor

А подскажите пожалуйста почему может игнорироваться параметр default_volume_type

у меня он вот тут /etc/cinder/cinder.conf:default_volume_type=vm_hdd_disks можно немного больше подробностей где он игнорируется?

еще вот тут /etc/cinder-working/cinder.conf:default_volume_type=VM-HDD

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

не указан

а можно последовательность действий и результат + ожидаемый результат?

а можно последовательность действий и результат + ожидаемый результат?

имеем 2 сеф-бекенда. Вот отрывки из cinder.conf: [DEFAULT] ... default_volume_type = ceph_ssd enabled_backends = ceph,sad_johnny [ceph] ... volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph [sad_johnny] ... volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = sad_johnny ————— openstack volume type list --long +--------------------------------------+------------+-------------------------+----------------------------------+ | ID | Name | Description | Properties | +--------------------------------------+------------+-------------------------+----------------------------------+ | 66cd8f0a-d5c8-4723-a46b-76cfaefef871 | ceph_ssd | all flash fast ceph | volume_backend_name='ceph' | | 3746f8d0-dfda-42ee-8071-91904f919415 | sad_johnny | sad_johnny ceph cluster | volume_backend_name='sad_johnny' | | c2f7e6b6-0ba9-40d1-9f55-66c96e1f12a4 | ceph | None | | +--------------------------------------+------------+-------------------------+----------------------------------+ После добавления всех конфигов порестартили cinder-scheduler и cinder-volume Теперь в horizon создаём новый инстанс, на вкладке source выбираем загрузку из image, с созданием нового вольюма. В итоге вольюм создаётся с типом "-", в сефе, с названием "sad_johnny", а ожидаем выставленный тип "ceph_ssd", как указанно в default_volume_type, и заселение вольюма в цеф с названием просто "ceph"

default_volume_type = ceph_ssd volume_backend_name = ceph

При этом, добавили одному имейджу --property cinder_img_volume_type=ceph_ssd, и если инстанс старотвать из него, то вольюм едет в правильный сеф, и имеет правильный volume-type

default_volume_type = ceph_ssd volume_backend_name = ceph

да, но у нас volume_type именно ceph_ssd называется, который под собой имеет бекенд с названием "ceph"

если мне память неизменяет то если указано имя в сторадже то нужно именно его указывать. а если не указан то имя равно имени секции

Нуу мы пробовали и "ceph" указывать, у нас есть и имя секции такое и volume_type тоже есть, правда к нему не привязан никакой бэкенд. Один фиг, при создании инстанса, вольюм создаётся с типом "-"

если мне память неизменяет то если указано имя в сторадже то нужно именно его указывать. а если не указан то имя равно имени секции

Где-то читал, что имя секции не роляет

Сегодня в доках

вот сейчас такая картина: верхний вольюм создан из обычного имейджа, и default_volume_type в cinder.conf проигнорировался, а нижний вольюм создан при выборе имейджа, в котором захардкожен property cinder_img_volume_type=ceph_ssd

Где-то читал, что имя секции не роляет

https://github.com/openstack/cinder/blob/fccd84cb2e10e673d61287483264638f7492d8ab/cinder/volume/volume_types.py#L166 - роляет. там если бежать глуубже обращение идет именно по имени секции а не параметрам в ней

нуу, и вон он идёт в базу: return db.volume_type_get_by_name(context, name) И volume_type у нас такой есть: openstack volume type list +--------------------------------------+------------+ | ID | Name | +--------------------------------------+------------+ | 66cd8f0a-d5c8-4723-a46b-76cfaefef871 | ceph_ssd | | 3746f8d0-dfda-42ee-8071-91904f919415 | sad_johnny | | c2f7e6b6-0ba9-40d1-9f55-66c96e1f12a4 | ceph | +--------------------------------------+------------+ Секция конфига всё же обозначает имя бэкенда, а не тип вольюма, не?

ну все верно. выбора из конфига идет по имени секции, а в бд пишется volume_backend_name

https://github.com/openstack/cinder/blob/fccd84cb2e10e673d61287483264638f7492d8ab/cinder/volume/volume_types.py#L166 - роляет. там если бежать глуубже обращение идет именно по имени секции а не параметрам в ней

Тогда возможно я пиздоглаз

я не могу пока найти код а проверятся ли что default_volume_type входит в enabled_backends

я не могу пока найти код а проверятся ли что default_volume_type входит в enabled_backends

Я вот не нашёл сегодня

если предроложить что кодер умный и сделал проверку. То по логике если не входи одно в другое взять первый который в enabled

казалось бы, но пока во всех тестах, которые я делал, брался второй

как секции расположены?

в примере выше нет ceph_ssd

а секции да, выше ceph

но она не enabled

вот и второй

enabled_backends = ceph,sad_johnny есть же

ceph_ssd

ща ща дойдет

)

такой секции нету. Я говорю, я пробовал делать default_volume_type = ceph результат точно такой же

type получался с прочерком, а вольюм уезжал в "sad_johnny"

enabled_backends = ceph,sad_johnny,ceph_ssd

ок, попробую

Зачем? Конфиг правильный!

enabled_backends = ceph,sad_johnny,ceph_ssd

ну да, тут вообще 3 бекенда, у меня всего 2

default_volume_type = ceph_ssd enabled_backends = ceph,sad_johnny 3

в смысле правильный? Человек описал бэкэнд но не за-enable его.

default_volume_type и enabled_backends суммируются, вычитаются. иное?

не путайте бэкенды и вольюм типы

не путайте бэкенды и вольюм типы

Да.

@KeksBeskvitovich openstack volume service list

выше есть там все 3

ой это типы

@KeksBeskvitovich openstack volume service list

нет такого, есть cinder service-list:

Пойдет.

хостов много, конфиги одинаковы везде

проверял

где ceph_ssd?

не путайте бэкенды и вольюм типы

ceph_ssd - это вольюм тип:

как связаны бекенд и волумтайп?

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

как связаны бекенд и волумтайп?

Например, openstack --os-username admin --os-tenant-name admin volume type set lvm \ --property volume_backend_name=LVM_iSCSI

https://docs.openstack.org/cinder/pike/admin/blockstorage-multi-backend.html#configure-block-storage-scheduler-multi-back-end

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

@KeksBeskvitovich а через консоль такая же ерунда, как и через даш?

фактически он лёг как раз в sad_johnny, а не в ceph, как ожидалось

пока не пробовал черзе консоль