а этого ой как бы не хотелось отбирать

Ограничение на действие upload_image)

5 сек

Ограничение на действие upload_image)

сапы не работают

и при этом ещё и тупо отваливается, не то что вам запрещено, а типа я начинаю лить, а потом просто пропадает 🙂

шапки вон как предлагают https://access.redhat.com/solutions/757613

воодушивила вот эта строка: Moreover upstream has started to discuss a way to do this in a saner way but it's likely to part of the Juno release.

вот я и думал, может уже что-то всё таки сделали

вот я и думал, может уже что-то всё таки сделали

А) Ну ты не до конца всю глубину проблемы описал. Тогда выходит что да, надо два API городить. Сходу чот не нахожу даже обсуждения фишки.

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

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

В смысле, без опенстека новая платформа?)

В смысле, без опенстека новая платформа?)

нет, опенстек в кубере 🙂

нет, опенстек в кубере 🙂

openstack-helm или свое что-то?

openstack-helm или свое что-то?

Хелм но писали его сами

Хелм но писали его сами

Поделитесь потом опытом использования, интересно сравнить с голым докером от Kolla (сейчас живем с этим и вроде все ок), openstack-helm скорее мертв, чем жив

Поделитесь потом опытом использования, интересно сравнить с голым докером от Kolla (сейчас живем с этим и вроде все ок), openstack-helm скорее мертв, чем жив

У вас лишнее слово helm в последней фразе

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

Всем привет. Никто не сталкивался с ограничением по скорости на заливку образа через glance в ceph? Через glance-client образ быстро доходит до glance сервера, там кешируется в память (через 10G интейфейс достаточно быстро), но вот потом сброс в rbd происходит долго, по метрикам будто упирается в 1G где-то на стыке с ceph. Ограничение точно не в сетевых интерфейсах. Что-то подобное было у кого-то тут? Скачивание образа с того же кластера проходит быстро, а вот заливка долго

Всем привет. Никто не сталкивался с ограничением по скорости на заливку образа через glance в ceph? Через glance-client образ быстро доходит до glance сервера, там кешируется в память (через 10G интейфейс достаточно быстро), но вот потом сброс в rbd происходит долго, по метрикам будто упирается в 1G где-то на стыке с ceph. Ограничение точно не в сетевых интерфейсах. Что-то подобное было у кого-то тут? Скачивание образа с того же кластера проходит быстро, а вот заливка долго

Веришь или нет, из твоего описания вообще ничего непонятно. Начни с тестирования производительности своего Ceph на запись. Прям вот поставь клиент на glance и с него пробуй.

Опять же, чтобы осмысленное что-то ответить нужно знать где расположен glance-api, какие сетевые интерфейсы там, какая конфигурация у ceph-osd серверов.

Всем привет. Никто не сталкивался с ограничением по скорости на заливку образа через glance в ceph? Через glance-client образ быстро доходит до glance сервера, там кешируется в память (через 10G интейфейс достаточно быстро), но вот потом сброс в rbd происходит долго, по метрикам будто упирается в 1G где-то на стыке с ceph. Ограничение точно не в сетевых интерфейсах. Что-то подобное было у кого-то тут? Скачивание образа с того же кластера проходит быстро, а вот заливка долго

Может быть такое что glance-api сервер и ceph-osd серверы в разных сетях и трафик маршрутизируется где-то чеез 1G интерфейс?

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

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

А, извини, запутался) Ну так что, ты вообще тестировал на запись то конкретно тот пул куда образы пишутся? Что там используется? Репликация? EC?

напрямую с сервера где glance-api не делали, надо сделать.

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

Виталий Тарасенко будет жить. Поприветствуем!

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

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

Комрады, всем привет! Openstack Pike, сторэдж Ceph, CentOS 7. В общем, ситуация такая. Клиент привез файл образа raw на 2Тб, там просто данные, надо сделать из этого образа диск, который будет доступен в проекте клиента. Единственная идея, которая мне пришла в голову, это залить образ в Глэнс, а потом развернуть из него диск внутри тенанта клиента. Я залил этот образ в Глэнс, но с созданием диска возникла проблема. Если пытаюсь создать диск через Горизонт, в разделе Диски, то при выборе образа, там нет нужного (который на 2Тб). Если зайти в Горизонте в раздел образов, то с нужного нельзя создать диск, вот скрин:

Если пытаюсь создать диск из консоли, у этого диска статус вываливается в ошибку. В логах Циндер-вольюм: ImageTooBig: Image 79a98128-8f81-4ee9-ae1a-fe8dcccec7c6 size exceeded available disk space: There is no space to convert image. Requested: 2147483648512, available: 778765328384 Вот это я не понял, что за "available: 778765328384"? Откуда берется это число? В пулах Цефа места достаточно

Нашел совет, что можно явно выставить образу параметр --min-disk под размер образа, это может помочь, но при попытке сделать это получаю ошибку в от Глэнса: ImageSizeLimitExceeded: The provided image is too large

Не пойму, куда копать. Коллеги, выручайте, кто сталкивался с подобным? Или может есть другой способ сделать из образа блочное устройство?

Не пойму, куда копать. Коллеги, выручайте, кто сталкивался с подобным? Или может есть другой способ сделать из образа блочное устройство?

Ищи /var/lib/horizon/tmp

Оно должно быть больше 4тб

Путь может меняться, но именно там конверт происходит

df -h на контроллере. Там видно, это отдельный раздел

Я в этом случае монтировал туда отдельный диск временно

Ищи /var/lib/horizon/tmp

Такой диры у меня нет, зато есть /var/lib/cinder/conversion/ это случайно не оно?

Запусти процесс ещё раз и посмотри в процессах где оно конвертит и на каком разделе уменьшается место

Хотя у тебя сразу сваливается. У тебя там всего 700гб

df -h покажи

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

А у тебя контроллер один?

3

Смотри все

Уже дошло) сейчас на остальных посмотрю

Но вообще проще конечно решить по другому. Сделать пустой диск и слить данные копированием с машины на машину

rbd-nbd map <poolname>/volume-<id>; dd if=filename of=/dev/nbd<N> ; rbd-nbd unmap /dev/nbd<N>

rbd-nbd map <poolname>/volume-<id>; dd if=filename of=/dev/nbd<N> ; rbd-nbd unmap /dev/nbd<N>

Что это за магия?

Мапишь волюм как блочное устройство, льеш в него свой образ, и никаких дополнительных 4 терабайт на синдер-волюмах не надо

rbd-nbd map <poolname>/volume-<id>; dd if=filename of=/dev/nbd<N> ; rbd-nbd unmap /dev/nbd<N>

Решил попробовать этот вариант, но не получилось подключить модуль NBD. Делал все как здесь: https://stackoverflow.com/questions/45419526/how-to-load-network-block-device-on-centos7 Но столкнулся с ошибкой: drivers/block/nbd.c:619:19: error: ‘REQ_TYPE_SPECIAL’ undeclared (first use in this function); did you mean ‘REQ_TYPE_SENSE’? sreq.cmd_type = REQ_TYPE_SPECIAL;

Тут пишут про это: https://centosfaq.org/centos/nbd-does-not-compile-for-3100-514262el7x86_64/

Если на диске просто данные, то с машины на машину проще всего перекинуть

Если на диске просто данные, то с машины на машину проще всего перекинуть

В смысле по сети, типа рсинка?

Ну если так хочется. Можно просто виртуалку поднять kvm рядом.

А можно через rbd import это провернуть? Создам в опенстеке диск, появится такая сущность, потом руками удалю блочное устройство непосредственно из Цефа, потом заимпорчу туда свой образ под именем которое было сгенерено для диска. Это вообще законно?

Не любишь простых путей?)

Не любишь простых путей?)

Да не) просто я за двое суток поспал часов 5, уже нихрена не соображаю, сроки/сраки горят)

Делаешь волюм в облаке. Цепляешь его к виртуалке в облаке

Отдельно делаешь диск из своего образа на другой машине, вне облака

Можно на хосте даже

Вяжешь по сети и копируешь

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

привет всем, есть тут те, у кого на rocky успешно создался кластер k8s?

привет всем, есть тут те, у кого на rocky успешно создался кластер k8s?

Ну у нас вроде как работает, но у нас свой чарт и свои контейнеры

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

зайдя в вм, вижу что подов нет вообще, даже служебных

и докер пс пустой

шедуллер говорит что не может достучатья до апи

что то ттипа dial tcp 127.0.0.1:8080: connect: connection refused

и все процессы в runc

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

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

А чем k8s разворачивался?

руками =) говорю же по инстуркции)

https://docs.openstack.org/install-guide/openstack-services.html

это моя первая инсталяцция опенстека, но в целом почти все заработало сразу

это моя первая инсталяцция опенстека, но в целом почти все заработало сразу

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

А все понял, у нас другое, у нас OS в кубе, а тут про куб в ОС

Ну Нова, Циндер, нейтрон работают)