Никому этот ваш SSL внутри компании не нужен

Сейчас фактически не поставить OKD/OpenShift пока свой CA не поднимешь и сертфиикат не выдашь на registry.

Порог вхождения сразу увеличивается.

если мы будем рекомендовать plain http, то будет очень стыдно :)

Не, надо написать что это плохо и мы все умрем, но опцию добавить ;)

так для этого есть механизм:
1) тикет в поддержку, но там тебя с высокой вероятностью пошлют, потому что случай редкий и есть воркэраунд
2) писать PR в machine-config-operator, но тут вообще может понадобится enhancement

пардон, не то тпример написал:

          [[registry]]
          prefix = "quay.io"
          location = "registry.local"
          insecure = true

теоретичски в OKD 4.5 мы можем это добавить, но уже в 4.6 мы юзаем апстрим, со всеми вытекающими

> 1) тикет в поддержку, но там тебя с высокой вероятностью пошлют, потому что случай редкий и есть воркэраунд

Мы бомжи, ковыряем OKD еще когда он не был GA. :)

та же самая беда и в OCP, так что даже ставить не придется

а какой workflow там? Сначала в OKD изменения, потом опеншифт пакуется из него или наооборот?

одновременно приходит и в OKD и в OCP nightlies. Только это меняет апи machine-config и влияет на несколько компонентов, а потому надо писать в github.com/openshift/enhancements/ предложение что исправить и как это повляет на oc/OLM/MCO

ОК, этот механизм понятен.

Надо только осилить и написать туда пропозал... :)

Кстати там много интересного - тот же metallb вроде думают прикручивать, local-storage-operator есть планы доделывать до юзабельного и много чего еще

https://github.com/openshift/enhancements/pull/450 самый интересный ящитаю

Ну это другая история. Тут надо всю спеку считай разрабатывать под 4.x. Разбираться как собирать тулзу, потом добавлять 1000500 зависимостей в федору через ревью, потом через ревью добавлять пакет. Наверное как собирать тулзу всё равно разбираться, а дальше посмотрим по сложности. Просто бинарник по policy сложить нельзя, можно только сборку из исходников сделать.

queueinformer_operator.go:290] sync {"update" "openshift-marketplace/community-operators"} failed: etcdserver: request timed out

у тебя etcd себя плохо чувствует:

2020-09-17T10:52:09.078050722Z 2020-09-17 10:52:09.077938 W | etcdserver: read-only range request "key:\"/kubernetes.io/serviceaccounts/openshift-kube-scheduler/localhost-recovery-client\" " with result "range_response_count:1 size:407" took too long (451.82714ms) to execute

каждые ~5 минут теряет лидера

queueinformer_operator.go:290] sync {"update" "openshift-marketplace/community-operators"} failed: etcdserver: request timed out

2020-09-17T10:52:09.078050722Z 2020-09-17 10:52:09.077938 W | etcdserver: read-only range request "key:\"/kubernetes.io/serviceaccounts/openshift-kube-scheduler/localhost-recovery-client\" " with result "range_response_count:1 size:407" took too long (451.82714ms) to execute

я думаю это случилось когда я nfs в internal-registry добавил...было много алертов...сейчас всё норм

etcd не использует internal registry, он а /var на мастерах