WIP: Implement deployment lifecycle hooks

[ironcladlou]

This PR tracks the effort to implement deployment hooks as specified in #1224.

[smarterclayton]

var _ Interface = &LifeycleManager{}

[ironcladlou]

Ah, fixed

[ironcladlou]

@smarterclayton In general, is the approach I'm taking here making sense? At first I was basically implementing the exec pod plugin inline in the existing controllers, and decided to try and abstract it behind a generic plugin system when it started getting out of hand. I hope it's not too much for the task at hand.

[smarterclayton]

Why isn't this run by the deployment process itself? Why does it need a controller?

[ironcladlou]

Will talk more tomorrow, but I found a problem with my approach when trying to deal with the higher level status persistence that has me thinking about other ways to approach the feature in general. Any ideas welcome right now- this POC may be the one I end up tossing now that I have more of the problems in my head.

[smarterclayton]

While having the deployment pod itself trigger the execution of the container may increase the permissions that pod needs, it means that the retry context and completion progress is tied to an execution of a pod. On the other hand, it may make reentrant behavior more difficult.

The argument in favor of that is that I would expect a complex custom deployment to invoke its own hooks, rather than also invoke separate hooks.

On Apr 6, 2015, at 8:00 PM, Dan Mace notifications@github.com wrote:

In pkg/deploy/controller/lifecycle/execnewpod/controller.go:

• kapi "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

• deployapi "github.com/openshift/origin/pkg/deploy/api"
  +)

+// ExecNewPodController keeps an ExecNewPodAction pod's status in sync with
+// its associated deployment.
+//
+// Use ExecNewPodControllerControllerFactory to create this controller.
+type ExecNewPodController struct {

• // deploymentClient provides access to deployments.
• deploymentClient deploymentClient
  +}

+// Handle syncs the action pod's status with its associated deployment.
+func (c *ExecNewPodController) Handle(pod *kapi.Pod) error {
Will talk more tomorrow, but I found a problem with my approach when trying to deal with the higher level status persistence that has me thinking about other ways to approach the feature in general. Any ideas welcome right now- this POC may be the one I end up tossing now that I have more of the problems in my head.

—
Reply to this email directly or view it on GitHub.

[ironcladlou]

We found a better way to go about this; I'll be revising the proposal and opening a new PR from a different branch tomorrow.