[chef] RE: Re: Re: Re: Push jobs vs SSH

["Fouts, Chris" < >]

I had the same lofty expectation on push jobs, only to realize that Mark says the truth, that is, Chef push jobs functionality is at its primitive stage.

 

Chris

 

From: Mark Mzyk [mailto:
Sent: Friday, February 06, 2015 10:49 AM
To:
Subject: [chef] Re: Re: Re: Push jobs vs SSH

 

Hi Eric,

The reason your expectations aren't being met is that push jobs is intended to be the building block (or primitive) on which more advanced features are built. Therefore it's going to feel more bare bones than you might otherwise expect. This is why it's open source and use cases are still being explored.

That said, and others will have to correct me if I'm wrong, as I'm not familiar with all of the push job capabilities, I believe you can do things like define groups, so then you can push to just certain machines by specifying the group. As far as running a single recipe, chef-apply gives you this capability, so you could trigger this with knife ssh or pushy to achieve that result.

Does that explanation help?

On your side note: yes, Chef server does use rabbitmq. Push Jobs uses zeromq instead, as I believe the desire was for a lighter weight message bus with less overhead than rabbitmq.

- Mark Mzyk

">Eric Horne

February 6, 2015 at 10:45 AM

Thanks Steven (and Hi!) I saw the video, but there isn't a comparison to ssh that I remember (maybe I should watch it again). I was sold on pushy being the next awesomeness, but now that I'm playing with it... it just looks like another ssh client (yes I know it's not using ssh at all) with some additional easy-to-use controls and reporting.

The video appears aimed at showing that the technology works as opposed to presenting use cases in which it is superior to other solutions. When is pushy better than knife ssh or an ssh call integrated into a recipe?

My expectations for pushy were a little more lofty, I guess. I was hoping for more integrated orchestration, the ability to run a single recipe on a system as opposed to just running chef-client to get everything (so I guess something more like ansible, but integrated into Chef). Something like: "push out THIS change" as opposed to "sync all changes now".

So.. all that said -- this isn't intended to be a critque of push; I honestly think I'm missing something somewhere along the line.

(on a side note, doesn't Chef already use rabbitmq?)

-Eric

">Hajducko, Steven

February 6, 2015 at 10:10 AM

One of the big benefits is speed.

Knife ssh uses a parallel ssh method. Chef push jobs use a message bus ( zeromq I believe ).

Here's a video that demonstrates the push job feature:

https://m.youtube.com/watch?v=yHub6E4DNvg

I also believe that push jobs are the way of the future over knife ssh.

-
sh

">Eric Horne

February 6, 2015 at 8:34 AM

What's the difference between chef push jobs and knife ssh?

I'm researching a use case for chef in which we want highly controlled deployments to orchestrate across several different systems. The traditional "pull" doesn't fit the bill well because it is difficult to get that to coordinate properly across systems.

From what I've read so far, chef push jobs are essentially a daemon running on the remote servers that allow arbitrary (but pre-defined/whitelisted) execution of commands. Aside from perhaps a cleaner white-listing concept (over forced-ssh), how is this different (better) than just using knife ssh?

I'm failing to see the benefits or use cases of chef push jobs over knife ssh. The documentation is lacking in terms of how it is intended to be used. Are push jobs better suited for different situations (and what are those situations?)

Thanks for the help!

-Eric