Skip to content
This repository was archived by the owner on Jan 28, 2026. It is now read-only.

Add callbacks to deployment events#124

Closed
MarkBorcherding wants to merge 17 commits into
newrelic:masterfrom
MarkBorcherding:before-after-callbacks
Closed

Add callbacks to deployment events#124
MarkBorcherding wants to merge 17 commits into
newrelic:masterfrom
MarkBorcherding:before-after-callbacks

Conversation

@MarkBorcherding

Copy link
Copy Markdown
Contributor

We need to tell our load balancer that our image is about to go down and to stop routing traffic to it. Similarly, we need to tell it when it comes back up and is ready for traffic again.

This adds the following callbacks to the task DSL

 task :production => :common do
   before_stopping_image do |server|
     my_loadbalancer.disable server.hostname
   end

   after_image_started  do |server|
     my_chat_server.post "#{server.hostname} started my image....waiting for health check"
   end

   after_health_check_ok do |server|
     my_loadbalancer.enable server.hostname
   end
 end

@kremso has some ideas on how to implement this differently, that may be more elegant in the end, but I think this approach is less intrusive to the existing code.

@relistan

Copy link
Copy Markdown
Collaborator

I'll check this out next week. I think @kremso's solution of using rake task dependencies is probably the better solution, but I'm not going to judge until I've spent some time looking at what you've contributed.

Thanks! :)

@relistan

Copy link
Copy Markdown
Collaborator

I actually got some time this afternoon to look at this. This looks very good. The API is probably cleaner to use than the rake DSL, as well. I feel like callbacks are a slippery slope to the mess that is Capistrano. But there is an undeniable need to use them. @kremso @didip @jessedearing any feedback?

@didip

didip commented Jun 13, 2015

Copy link
Copy Markdown
Contributor

The code is clean and tested, I like it.

We need to tell our load balancers about these two events. We can
provide callbacks that allow us to do so.
Since prepend is a Ruby 2.0 thing, there is probably a better way to get
this functionality without sprinkling all the callbacks into deploy.
This should let the callbacks have a chance to execute first and call up
to the deploy module at the proper time.
My initial approach used some Ruby 2.0 features. I thought it would be
good to ensure backwards compatibility to older Rubies.
@MarkBorcherding MarkBorcherding force-pushed the before-after-callbacks branch from 8621c38 to f0ef65f Compare June 17, 2015 02:22
@MarkBorcherding

Copy link
Copy Markdown
Contributor Author

I rebased the feature to keep it up to date with current master. I've already added comments in ready.

@kremso

kremso commented Jun 21, 2015

Copy link
Copy Markdown
Contributor

I think that this is simple enough after all, and covers all our use cases.

@intjonathan

Copy link
Copy Markdown
Contributor

cc @cory-johannsen

@jessedearing

Copy link
Copy Markdown

I like the interface. It's pretty clean and simple.

For any sort of callback mechanism I prefer a generalized event emitter pattern for callbacks. That being said I think this good to merge.

@MarkBorcherding

Copy link
Copy Markdown
Contributor Author

This is a little better now. There is still some commonality that could come out.

@intjonathan

Copy link
Copy Markdown
Contributor

@MarkBorcherding any chance you could rebase this bad boy?

@MarkBorcherding

Copy link
Copy Markdown
Contributor Author

I'm so far removed from using Docker, and it's fallen too far behind.

@intjonathan

Copy link
Copy Markdown
Contributor

No worries, thanks for checking in.

intjonathan pushed a commit that referenced this pull request Jan 19, 2017
@intjonathan

Copy link
Copy Markdown
Contributor

Supplanted by #176

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants