" type="cite">
" photoname="Mark Mzyk"
src="jpgL8B7eTpZbR.jpg"
name="compose-unknown-contact.jpg" width="25px" height="25px">
Friday, February
06, 2015 7:49 AM
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
" photoname="Eric Horne"
src="jpgL8B7eTpZbR.jpg"
name="compose-unknown-contact.jpg" width="25px" height="25px">
Friday, February
06, 2015 7: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
" photoname="Hajducko, Steven"
src="jpgLzsREg0qBr.jpg" name="postbox-contact.jpg"
width="25px" height="25px">
Friday, February
06, 2015 7: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=yHub6E4DNvgI
also believe that push jobs are the way of the future over knife ssh.
-
sh
" photoname="Eric Horne"
src="jpgL8B7eTpZbR.jpg"
name="compose-unknown-contact.jpg" width="25px" height="25px">
Friday, February
06, 2015 5: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