Здравствуйте, Pauel, Вы писали:

НС>>У меня текущий продукт ровно по такой схеме и построен. Только при чем тут заголовки с варнингами?
P>При том, что трафик после такого гатевея уже внутренний

Да. Я тебе больше скажу — у меня там целая пачка кастомных хидеров бегает. Но вот варнинги там точно не нужны.

P>, а раз так, то на него можно навешивать какие угодно капабилити.

Можно, но в хидерах не нужно. Это, по сути, статическая информация. Меняется при деплое, либо, в совсем уж экзотических случаях типа А/В, при изменении конфигурации. В условиях кубера такое обычно реализуют при помощи custom resource, из которого сервисы либо напрямую читают, либо их кормит этим специальный оператор. Так если для публичного апи какую то сомнительную пользу из обсуждаемого хидера еще и можно извлечь, то внутри кластера такие варнинги как собаке пятая нога.

P>Например, гатевей будет блокировать реквесты от конкретных юзеров, клиентов, если варнинги идут больше недели.

Такие вещи, как я уже сказал, обычно делаются при помощи CR и оператора (либо, если нужна супероперативность, с каким нибудь промежуточным хранилищем типа редиса или консула), а не засером всего внутреннего трафика дублирующейся информацией, которую придется как то обрабатывать всем сервисам (ну либо вешать на все сервисы специальные RP как в istio, что отдельная история).

P>1. сhangelog это в чистом виде человеческий фактор. например, девелопер не просмотрел, не учел последствия.

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

P>2. И вот ты прочел changelog, проверил все что мог, тебя тесты зелёные. Твои действия? Что конкретно ты будешь предпринимать
P> в такой вот ситуации? Есть хороший пример, что бы не абстрактно рассуждать? ты то не надеешься на варнинги, как с проблемой будешь работать?

Вопрос непонятен. О какой проблеме речь?

НС>>Заголовки тут не спасут.
P>Зато это уже можно автоматизировать.

Можно. Но заголовки — лишняя сущность для этого.

P> А вот как автоматизировать обработку changelog депенденсов 2го уровня — не ясно.

Еще раз — 2 уровень заголовки тоже не отслеживают (если конечно ты не будешь эти заголовки пропогейтить по всей цепочке, что совсем уж дичь если сопоставить с исходной задачей).
Ты выкинь из головы все технические подробности и посмотри на проблему сверху. У тебя уже ровно в момент прихода реквеста непосредственно в сервис уже все известно и понятно. От того что ты потом эту информацию погонишь с респонсом обратно — ни новой информации, не улучшения доступности существующей не дает. Это абсолютно бессмысленное с точки зрения системы действо. Единственное что может быть полезно это если эти заголовки кто то в какой то момент увидит глазами (ну там всякие HATEOAS, да). Но в данном случае это ничего не даст, того же эффекта можно достичь убиранием заобсоличеных методов из OpenAPI definition, что обычно и так делается автоматом.

P>>>Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?
НС>>Заголовки тут не спасут.
P>Это смотря как ты ими пользоваться будешь.

Расскажи как.