Всем привет !)
Подскажите, пожалуйста, ситуация следующая:
есть проект sf2.8, я проделал все изменения из upgrade-3.0.md и могу обновить в composer.json версию до 3.0 и нажать инстал. Вопрос такой: как быть с другими зависимостями ? их же тоже нужно синхронизировать под 3.0 ?)

Обычно зависимости зависимостей тоже апают, поэтому пока ты все версии не подгонишь правильно, ты не сможешь успешно выполнить composer update

и для этого полезно помнить composer why vendor/lib и composer why not vendor/lib

кто эти люди, которые не умеют читать доку????

Хотел задать такой вопрос, у нас есть кубер, и на подах крутятся воркеры на определенное количество итераций. Все исходники лежат внутри контейнера как и папка с кешем и логами. Как я понимаю, при рестарте идет прогрев кеша заново. Есть ли практика работы с k8s и symfony, когда у тебя все контейнеры делят один volume с исходниками? Допустим один контейнер уже прогрел кеш, и при старте это не надо делать всем остальным

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

Рано вам еще кубер значит

Volume это что ? Диск ? У тебя много нод в различніх зонах, как шарить один диск между ними ? Можно взять nfs, но зачем. Как знать что надо прогревать кэш? А если редеплоить только часть подов.

У тебя кеш пару секунд грузится, в чем проблема подождать ?

Всем привет, можно ли как-то request поля для swagger документации смаппить с дто? Не могу найти что-то, неужели руками описывать каждый параметр?

Да можно

Почему не собирать кеш при сборке image?

Прогревай кэш при сборке образа

А уже...

Спасибо большое) не подумал об этом)

Логи не должны лежать внутри, а лететь в stdout. Кеш в образе должен быть, как и выключенная валидация опкеша. Волюмов вообще не должно быть примерно никогда

Лучше наоборот, с openapi генерить код

Из чатика k8s)

Базы в кубере это довольно рисковое занятие. Зачем это делать если есть RDS?