Brian Grant

The story I heard (and this was back in 2016ish, secondhand and in passing, so take however many grains of salt), was:

When the community decided to rework replica management, DeploymentConfig managing ReplicationControllers was proposed by the folks from Red Hat, but the community eventually went with a different proposal of Deployment managing a new resource called a ReplicaSet.

The key issue seems to be kubernetes/kubernetes#1743, which almost five years later reads as @smarterclayton proposing the adoption of DeploymentConfig as a result of existing discussion and @bgrant0607 taking off from there, paring it down and bending it into a different shape.

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?