Brian Grant

The OpenShift doc text makes it sound like Kubernetes Deployment is a lineal descendant of OpenShift DeploymentConfig.

Fair enough! I'm too ignorant on the topic to know for certain either way.

Always a ton of nuance here - a lot of DC design was inspired by heroku deployments, but key difference early was deployment tries forever and a DC stops if they can’t rollout.

Over time they both evolved closer - today if you don’t want hooks or custom rollout logic deployments are better. We also haven’t evolved deployments much in the past few years - it’s possible it’s time for some new workload controller experiments in the wild

What kinds of things do you think Deployments should handle (or handle better) that they don’t right now? Anything come to mind specifically?

Condition summarization is huge - users should not have to look at a pod or RS to diagnose failure reason (stuck because PSP rejected, or quota, or because a secret doesn’t exist).

I do not like that deployments reconcile RS (so you can’t have an admission webhook that resolves a tag to a digest on an RS). DCs don’t do that which allows admission to mutate the body.

I would like to have the ability to gate deployments on pre and post conditions more easily - whether via a custom controller for specific deployments (deployment strategy “canary with traffic mirroring”) or something innate. Knative does some of this but should be native