ты что-то интересное рассказывал что файберы "вне луа-мира" ?

Для уточнения, мало ли это только на моей машине:

tarantool --version
Tarantool 2.5.1-76-g39f744da1
Target: Linux-x86_64-RelWithDebInfo
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_BACKTRACE=ON
Compiler: /usr/bin/cc /usr/lib/ccache/g++
C_FLAGS:-g -O2 -fdebug-prefix-map=/build/tarantool-2.5.1.76=. -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -std=c11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-format-truncation -Wno-gnu-alignof-expression -fno-gnu89-inline -Wno-cast-function-type
CXX_FLAGS:-g -O2 -fdebug-prefix-map=/build/tarantool-2.5.1.76=. -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -std=c++11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-format-truncation -Wno-invalid-offsetof -Wno-gnu-alignof-expression -Wno-cast-function-type

Ставил из стандартных пакетов на ubuntu

Легкое поверхностное заглядывание в сорсы показало что вроде файбер стек выделяется слаб аллокаторо - но возможно не ареновским

А должны быть вообще какие-то ограничения по памяти для файберов? Или это мыслилось это так: "создавай, пока память не треснет"? Просто тоже смотрел исходники, но по диагонали и не увидел ответов на свои вопросы :)

Вообще на страничке по модулю fiber про ограничения памяти вообще вскользь упомянуто, и то про fiber storage: fiber_object.storage
Local storage within the fiber. It is a Lua table created when it is first accessed. The storage can contain any number of named values, subject to memory limitations. Naming may be done with fiber_object.storage.name or fiber_object.storage['name']. or with a number fiber_object.storage[number]. Values may be either numbers or strings.

cartridge = приложение?
role = модули приложения?

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

т.е. к примеру у меня сайт, на нем три сервиса:
1. сервис комментариев
2. сервис авторизации
3. сервис истории действий

то сервисы нужно раскидывать на три разных картриджа? Чтобы при обновлении функционала в каком-либо из сервисов не перезагружать картридж со всеми тремя сервисами, а только тот на котором крутится сервис?

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

пока нет ответа

фактически все сервисы должны обращаться в базу или к токен-сервису и получать id пользователя по token_id

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

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

Ок, ждём-с, когда появится или найдется :)

Я попытался найти корреляцию с каким-нибудь юлимитом, но чет не получилось.
Зато получилось такое

tarantool> collectgarbage()                                                                          
LuajitError: not enough memory
fatal error, exiting the event loop

))

«Простого» reload в распределённом приложении мне кажется и не может быть.

Приветствую!
Я тоже думал о том как в картридже+vshard организовать обновление конфигурации без простоев - для нас это важно.
Пока у меня мысль движется в стороне подхода аналогичного zelando для PG.
Там ребята ввели слой хранимок и доступ к данным выполняли только через них ( в vshard - это так же).
А для наката релиза создавалась новая схема с именем api_2020_45 ( потом 46  и т.д.) - и в нее загружалась полностью новая версия апи для работы с данными.
После этого обновлялся приклад.
После этого старая версия схема удалялась (когда никто уже ей не пользовался).
При этом изменения между релизами должны быть обратно совместимы на 1-2 релиза назад.

Насколько я понимаю подход - в целом это можно реализовать в vshard'е:
1. Выкатываем обновления на слой хранилищь - создается новый спейс с новыми версиями функций, права доступа и т.д.
2. Выкатываем обновления на роутеры - создаем новый спейс с новыми версиями функций, которые используют новый спейс в хранилищах
3. обновляем (возможно постепенно) приклады - они начинают работать с новой версией API (может нужна доработка на стороне приклада, а может просто имя спецса для вызова функций поменять).

Хотел узнать мнение более близко работающих с этим коллег.
Вопрос в том как такое создание нового спейса удобнее всего запускать в кластере.

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

это хорошо - но возможность быстрого отката релиза - тоже важная функция

Версионирование апи и хотрелоад в принципе ортогональны.
Облако пользовалось подходом, который упомянул Илья, ещё в версии 1.5
Хотрелоад просто помогает выкатывать это самое новое апи с нулевым даунтаймом