| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Vivek Singh <vivek.singh@msystechnologies.com>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is inspired by "use_inline_resources".
Setting `unified_mode false` in a resource would be the existing
behavior with separate compile/converge phases.
Setting `unified_mode true` in a resource will eliminate the converge
phase. Reverse notifications and delayed notifications will still
fire. The resource action will behave like all resources are executing
at compile time.
As a aside, notifications have never worked for resources firing at
compile time. This implementation gets that behavior correct so
that notifications will work.
Of course forward immediate notifications to resources not yet declared will not
be possible.
Setting `resource_unified_mode_default true` in `Chef::Config` would
turn off the split compile/converge mode for every custom resource.
NOTE: This does not affect recipe mode at all.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
enforce pretzels.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
convert kind_of? to is_a?
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
This gives a speed boost since rubygems does not have to scan through
every gem in the gemset in order to find the file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
See the PR for details on this change.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
because surfing through Objectspace makes kittens cry
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to poise's approach but has a few differences.
Similarly to poise, the base behavior of notifications and find() and
lookup() on the resource collection is changed to be 'recursive' and
to search in outer contexts for resources and will return them by
default.
There are find_local() and lookup_local() methods added to allow for
bypassing the recursion and making sure to throw exceptions if the
current run_context does not have any matching resources.
The CHEF-3694 resource cloning code has been modified to call the
lookup_local() API and not to be recursive because we believe that
nobody in their right mind would want that behavior (and resource
cloning should eventually be removed). So the behavior of resource
cloning should remain unchanged.
The behavior of delayed notifications to resources outside of the current
run_context is slightly different than what Poise has been implementing.
The delayed notification will run in the run_context of the resource
that is being notified. I think Poise tends to bubble up to the nextmost
wrapping resource context (as opposed to Poise's subcontext_block or
notifying_block contexts). This code I think is conceptually simpler to
reason about, and I think it gets the use case right where if you're
notifying a service resource in the outermost run_context from within
multiple wrapping resources that it correctly bubbles out to the
outermost run context and will notify with all the other delayed
notifications at the end of the chef client run.
Another useful feature of the delayed notification behavior is that if
we do implement notifying_block or subcontext_block that each block can
get its own delayed notification run and any resources that are inside
of that block can run in the delayed notification phase of that block
(while still being able to notify resources outside of the block and
having those delayed notifications run in the receiving resources
run_context). This will let us implement an often-requested feature for
having "notifications delayed to the end of a block/recipe" instead of
having to do all notifications absolutely immediately or delayed to the
end of the chef run.
This code also cleans up the object model a little bit. All of the
state about notification collection is now hanging off of the
run_context -- the delayed_actions have been moved from the Chef::Runner
to the Chef::RunContext. Hanging it off of the Chef::Runner would have
been very difficult to 'target' from other run_context's without adding
a pointer back from the RunContext to the Runner and that feels like the
wrong object model. The RunContext is now responsible for all of its
notification state, while the Runner is responsible for wiring up
the notifications across different run_contexts.
Note that it will not be possible to send a notification to a
run_context which has already been converged. That seems to make sense
to me and the search API on the resource collection does not support
returning resources from run_contexts that are children, only parents
(and we don't actually hold onto pointers to child run_contexts and
they may be garbage collected).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4174 Style/SpaceInsideHashLiteralBraces
1860 Style/SpaceAroundOperators
1336 Style/SpaceInsideBlockBraces
1292 Style/AlignHash
997 Style/SpaceAfterComma
860 Style/SpaceAroundEqualsInParameterDefault
310 Style/EmptyLines
294 Style/IndentationConsistency
267 Style/TrailingWhitespace
238 Style/ExtraSpacing
212 Style/SpaceBeforeBlockBraces
166 Style/MultilineOperationIndentation
144 Style/TrailingBlankLines
120 Style/EmptyLineBetweenDefs
101 Style/IndentationWidth
82 Style/SpaceAroundBlockParameters
40 Style/EmptyLinesAroundMethodBody
29 Style/EmptyLinesAroundAccessModifier
1 Style/RescueEnsureAlignment
|
| |
|
| |
Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"
|
| |
|
| |
Created via git ls-files | xargs perl -pi -e "s/(Copyright.*?), Opscode(,)? Inc(\.)?/\\1, Chef Software Inc./gi"
|
| |
|
| |
Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
| |
|
|
|
|
|
| |
This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Many files/classes depend on Chef::Platform just to use the `windows?`
method. The part of Chef::Platform that maps providers to platforms has
very heavy dependencies (which may trigger circular deps when loading
some files) which are not needed for most users of Chef::Platform.
|
| |
|
|
| |
The opscode/chef repository now only contains the core Chef library code
used by chef-client, knife and chef-solo!
|
| |
|
|
| |
all with proper deps
|
| |
|
|
| |
do load_current_resources every time, or miss state changes in single statements
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Made the runner report back its errors, instead of throwing a useless stack:
aj@junglist (branch: master) ~/chef$ sudo ./bin/chef-client -l info -c ./examples/config/chef-solo.rb
INFO: Starting Chef Run
ERROR: file[/tmp/glen] (/home/aj/git/chef/examples/config/cookbooks/tempfile/recipes/default.rb line 1) had an error:
./bin/../lib/chef/runner.rb:85:in `converge': undefined local variable or method `e' for #<Chef::Runner:0xb6bd5360> (NameError)
from ./bin/../lib/chef/resource_collection.rb:59:in `each'
from ./bin/../lib/chef/resource_collection.rb:58:in `each'
from ./bin/../lib/chef/runner.rb:59:in `converge'
from ./bin/../lib/chef/client.rb:141:in `converge'
from ./bin/../lib/chef/client.rb:52:in `run'
from ./bin/chef-client:65
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
