As mentioned on IRC it may be useful to do custom deployment strategies (deployment executed by non core controller) first, which would allow this to be built as an extension controller (using observe or higher level tools) that applied hooks before / after deployment. I think process driven deployments are something it should be possible to build easily, and this is really a variant of a custom deployment. If you can spawn a side proposal only covering how someone could define a custom strategy we could have a multistage approach to hooks which makes Kube more extensible and reduces risk in the design process.

Re: need for hooks Right now 50-60% of our ootb web app examples that use a DB use the hook to initialize schema, so very relevant from the "I want to build something self contained that dtrt". Somewhere upwards of 70% of the ruby apps running on openshift online use the hook as a rails migration step. In enterprise environments, we've seen hooks used extensively with JEE apps to run mid migration updates with recreate strategies (clear cache, etc). I would those two examples are the most critical for ease of use in the use cases we target, but both of those examples benefit because of openshift's triggered deployments (via docker builds or tagged images resulting in images being changed automatically). If you don't have that capability, you are likely using custom scripting or Jenkins to drive your deployment updates, and you probably have a place to insert the hook logic. So a real philosophical question is - if you don't have a development flow that is innate / integrated with Kube, you'll be able to do hooks if you want. The hooks being on deployments gives a declarative tool for running something like pre-start but at a larger logical level for anyone performing deployment spec mutations - is that innately valuable to everyone, or just those integrated flows. I'd like to demonstrate a generic trigger controller (annotation that can result in a mutation of a deployment / daemonset / petset based on the latest level state of some external resource like a tagged image or git repo or URL) but I'm trying to close the partial object retrieval story first so I can do it more efficiently. But even that sort of tool is not fundamental, since many other workflows exist. The reason we focus on triggers is because they emphasize periodic refresh of cluster state (new db image) without user intervention, but without failed deployments those triggers could push resources into failing states. But as we talk about this a lot it really does highlight how OpenShift's dev workflow is opinionated and reinforcing (image resources -> triggers -> hooks -> failed deployments). If each of those pieces hangs on the other, it makes each individual piece in isolation less valuable. The fact we run the deployment in a pod also reinforces that - it's easy for someone to tweak the default deployment logic because we already have the concept of custom code running on the users' behalf in a pod. Perhaps we need to assess how someone like OpenShift can correctly implement the opinionated, reinforcing, easy deployment workflow on top of deployments first (which goes to the custom deployment question). That's more "custom workflow on top of Kube". While that complicates the movement of openshift users to deployments, it empowers others to build their own workflows.