Open vdice opened 7 years ago
let's see if we can distill this into a base case which we can hopefully ship a PR and functional test upstream to helm.
It is a possibility that this is due to a k8s regression (been running v1.5.x
in my testing); perhaps related: https://github.com/kubernetes/kubernetes/issues/23013
Adding this to the v2.15 milestone. We'll want to re-try this on a v1.6.x cluster. As it stands, we've added deis/registry-proxy
back into CI as features have come in with the Workflow v2.14 milestone.
This issue was moved to teamhephy/workflow#27
In order to switch over from our in-house registry-proxy to the official/upstream
kube-registry-proxy
(as original PR https://github.com/deis/workflow/pull/734 proposed) we will need to sort out the following issue when upgrading.v2.12.0 release candidate testing showed that after a Workflow install that uses the in-house variant of
deis-registry-proxy
(say,v2.11.0
), when one goes to upgrade (helm upgrade luminous-hummingbird workflow-staging/workflow --version v2.12.0
), although thedeis-registry-proxy
pod appears to have been removed, the newluminous-hummingbird-kube-registry-proxy
sometimes does not appear due to a host port conflict: