GM
Если есть права в вебконсоли, то и в oc есть
Size: a a a
2020 March 02
FM
Коллеги, такой вопрос OpenShift 4 на openstack хорошая идея, кто-то реализовывал подобным образом?
VR
я вчера пробовал OKD4 на опенстаке - нужен еще один пулреквест смерджить. OCP 4 работает, но я не долго им пользовался
B
Можно где-нибудь почитать, что именно происходит в подах, которые в названии содержат -deploy ?
FM
я вчера пробовал OKD4 на опенстаке - нужен еще один пулреквест смерджить. OCP 4 работает, но я не долго им пользовался
отлично, спасибо
MS
OCP4 на OpenStack хорошо работает. OKD4 на OpenStack вчера опять пробовал. Там не завелось.
VR
Michael Silich
OCP4 на OpenStack хорошо работает. OKD4 на OpenStack вчера опять пробовал. Там не завелось.
А попробуй
в инсталлконфиге?
quay.io/vrutkovs/okd-release:4.4-openstackfix c imageContentSources:
- mirrors:
- quay.io/vrutkovs/okd-release
source: registry.svc.ci.openshift.org/origin/4.4-2020-02-28-211838
- mirrors:
- quay.io/vrutkovs/okd-release
source: registry.svc.ci.openshift.org/origin/release
в инсталлконфиге?
VR
надеюсь что "не завелось" == "воркеры не джоинились?"
VR
Можно где-нибудь почитать, что именно происходит в подах, которые в названии содержат -deploy ?
я не видел полноценного описания, оно где-то в пучинах репы origin. Но если кратко - создается ReplicationController и ожидается когда оно задеплоит все поды
MS
нет, тоесть не совсем. Первый раз оно подняло 3 мастера, но сджоинилось только 2. Потом начали подниматься воркеры, но они получали только 500 ответ
VR
ага, потому что они неправильный IP светят. Не уверен насчет пропащего мастера
MS
Во второй раз бутстрап нода несмогла найти свой ignition конфиг в свифте
OS
Можно где-нибудь почитать, что именно происходит в подах, которые в названии содержат -deploy ?
Тоже интересно, кроме того что там выполняется логика деплоя деплоя когда то давно нигде не видел описания
s
я не видел полноценного описания, оно где-то в пучинах репы origin. Но если кратко - создается ReplicationController и ожидается когда оно задеплоит все поды
Интересует кто и в какой момент прописывается id юзера и capabilities
VR
Интересует кто и в какой момент прописывается id юзера и capabilities
так это либо в спеке DeploymentConfig прописано - либо берется из доступного scc
s
так это либо в спеке DeploymentConfig прописано - либо берется из доступного scc
В спеке не указываем. Имеете ввиду scc restricted? Используем mutating webhook и он требует эскалации прав. Но если напрямую указать в спеке - все норм. Думал может из scc данные патчатся тоже хуком каким
VR
В спеке не указываем. Имеете ввиду scc restricted? Используем mutating webhook и он требует эскалации прав. Но если напрямую указать в спеке - все норм. Думал может из scc данные патчатся тоже хуком каким
ага, но патчатся они не хуком, а он внутре openshift-api-server
s
ага, но патчатся они не хуком, а он внутре openshift-api-server
не подскажете в случае mutating webhook где лучше брать параметры securitycontext, от чего наследовать? пытался наследовать от поды до мутации - но там еще нет информации из scc (на rc тоже нет). напрямую из scc не правильно - может быть назначен не стандартный... пока не нашел оптимального варианта)
VR
не подскажете в случае mutating webhook где лучше брать параметры securitycontext, от чего наследовать? пытался наследовать от поды до мутации - но там еще нет информации из scc (на rc тоже нет). напрямую из scc не правильно - может быть назначен не стандартный... пока не нашел оптимального варианта)
а что вебхук делает и зачем ему id юзера с capabilities? В случае restricted у юзера вообще фейковый ID
s
а что вебхук делает и зачем ему id юзера с capabilities? В случае restricted у юзера вообще фейковый ID
хук добавляет инит контейнер при определенных условиях. ему id юзера и capabilities не нужны. но если пода попадает под мутацию то она не патчит securitycontext из scc и стартует под рутом. приходится указывать securitycontext в хуке. вот и хотел эти данные наследовать от какого-то объекта