I had a great weekend getting Chef up and running on some lab kit,
looking at it as an alternative to homegrown scripts and Puppet. It’s an
impressive system so firstly thanks for writing and sharing it
I was wondering about the no-op stuff hinted at in CHEF-13. For me the
ability to eyeball proposed changes on (a sample of) nodes is pretty
important, both for avoiding silly mistakes whilst learning the ropes
and as a checkpoint before rolling out scarily large changes.
If Chef has this ability I can’t find it, and if it doesn’t then I’m
wondering if the problem is something a keen Rubyist could work on. Only
48 hours I’m admittedly naive about Chef’s internals, it might be a hard
one that needs serious attention from core developers rather than me
blundering in!
Sorry if this is a FAQ or similar, I couldn’t find much mention of it
other than the ticket.
On Mon, Nov 30, 2009 at 2:28 AM, jon stuart lists@zomo.co.uk wrote:
I was wondering about the no-op stuff hinted at in CHEF-13. For me the
ability to eyeball proposed changes on (a sample of) nodes is pretty
important, both for avoiding silly mistakes whilst learning the ropes
and as a checkpoint before rolling out scarily large changes.
It is not implemented yet. I believe the problem is that you would
have to write support for it into every provider individually. In the
interim, you would have to bail on all providers that didn't support
it. Which while running in noop mode is probably fine because you
weren't going to do anything anyway, it would take a concerted effort
to get a full noop run working all the way through.
Sorry if this is a FAQ or similar, I couldn't find much mention of it
other than the ticket.
On Mon, Nov 30, 2009 at 2:28 AM, jon stuart lists@zomo.co.uk wrote:
I was wondering about the no-op stuff hinted at in CHEF-13. For me the
ability to eyeball proposed changes on (a sample of) nodes is pretty
important, both for avoiding silly mistakes whilst learning the ropes
and as a checkpoint before rolling out scarily large changes.
It is not implemented yet. I believe the problem is that you would
have to write support for it into every provider individually. In the
interim, you would have to bail on all providers that didn't support
it. Which while running in noop mode is probably fine because you
weren't going to do anything anyway, it would take a concerted effort
to get a full noop run working all the way through.
Ah right, thanks for the clue-in. So definitely in the non-easy category!
I'll continue to play with Chef regardless, its strengths demand it
On Mon, Nov 30, 2009 at 3:42 AM, jon stuart lists@zomo.co.uk wrote:
Ah right, thanks for the clue-in. So definitely in the non-easy category!
Actually, I think it is easy, but will take a bit of time for someone.
I think it'd be a great way for someone new to chef to get intimate
with the code base.
I have been testing chef configuration on several virtual machines.
Then you can actually test them and then tear them down and rebuild
them from time to time.
On Mon, Nov 30, 2009 at 2:28 AM, jon stuart lists@zomo.co.uk wrote:
I was wondering about the no-op stuff hinted at in CHEF-13. For me
the
ability to eyeball proposed changes on (a sample of) nodes is pretty
important, both for avoiding silly mistakes whilst learning the
ropes
and as a checkpoint before rolling out scarily large changes.
It is not implemented yet. I believe the problem is that you would
have to write support for it into every provider individually. In the
interim, you would have to bail on all providers that didn't support
it. Which while running in noop mode is probably fine because you
weren't going to do anything anyway, it would take a concerted effort
to get a full noop run working all the way through.
Ah right, thanks for the clue-in. So definitely in the non-easy
category!
I'll continue to play with Chef regardless, its strengths demand it
On Mon, Nov 30, 2009 at 2:28 AM, jon stuart lists@zomo.co.uk wrote:
I was wondering about the no-op stuff hinted at in CHEF-13. For me the
ability to eyeball proposed changes on (a sample of) nodes is pretty
important, both for avoiding silly mistakes whilst learning the ropes
and as a checkpoint before rolling out scarily large changes.
It is not implemented yet. I believe the problem is that you would
have to write support for it into every provider individually. In the
interim, you would have to bail on all providers that didn't support
Providers that don't provide no-op functionality need only barf when
it's asked for (controlled by the code which calls the provider)[0]. If
chef is running in op mode, legacy (as they would then become) providers
can simply run as specified, optionally emitting a warning, because
overall there'd be no change from the status quo.
Matthew
[0] It should be noted that I've never looked at the chef code so I may
well be talking out of my backside. User discretion advised.
--
I must take issue with the term "a mere child", for it has been my
invariable experience that the company of a mere child is infinitely
preferable to that of a mere adult.
-- Fran Lebowitz
