| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
More or less stolen from the apt cookbook, but tweaked and fixes a heap
of bugs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
This reverts commit e25b75e9fcd26ccc9c9094a43b614306de1047db.
|
|\
| |
| | |
Revert PR #1796: make mount resource options-ignorant again.
|
| |
| |
| |
| |
| | |
Closes issue #4056, although as discussed in that issue, we still need followup design and
implementation work to make the mount resource behave in a safe and unsurprising way.
|
|/ |
|
|\
| |
| | |
Improve the docs generated by knife cookbook create
|
| | |
|
|\ \
| | |
| | | |
Add option to set knife ssh timeout
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/
|
|
|
|
| |
see https://github.com/whitequark/parser/issues/283
if rubocop works around this bug then we can revert this patch.
|
|\
| |
| | |
Subversion provider should respect proxies
|
| | |
|
|\ \
| |/
|/| |
Improve wording in Knife
|
| | |
|
|\ \
| | |
| | | |
allow use_inline_resources for core chef providers
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* removes the DSL from InlineResources class
* ActionClass is now responsible for mixing the DSL into
action classes
* apt_update provider converted over to use new syntax
- does not need to mixin DeclareResource DSL
- declares use_inline_resources
- uses declare_resource instead of build_resource
- converts def action_stuff to action :stuff
- uses an execute resource instead of shell_out!
- does not need the converge_by to update the action
|
| | | |
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Make handling of proxies more consistent
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Always use `*_proxy` environment variables.
* Make a `ChefConfig::Config.proxy_uri` method that gets used by
`Chef::Provider::RemoteFile::FTP` and `Chef::HTTP::BasicClient`.
* Remove `env` method from `Chef::HTTP::BasicClient` (using
`stub_const("ENV", ...)` in specs instead.)
* Remove `http_proxy_user` and `http_proxy_pass` methods from
`Chef::HTTP::BasicClient` (replaced by functionality in `ChefConfig`.)
|
|\ \ \
| | | |
| | | | |
Log platform along with client version and pid.
|
| |/ / |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
this module was created out of a bit of excessive paranoia instead of
simply adding mixins that we always use with Chef::DSL::Recipe directly
to Chef::DSL::Recipe. lets try and YAGNI this class and just add it
directly. these modules are already injected into everyone's recipes
and providers, so I can't imagine a huge amount of backcompat breaks.
|
| |
| |
| |
| |
| |
| | |
Chef::DSL::Recipe::FullDSL.send(:include, MyModule) will now patch all
its descendants that it has been included into (works the way actual
inheritance works now).
|
|\ \
| | |
| | | |
Remote file download progress
|
| | |
| | |
| | |
| | | |
Add tests around progress output and tidy up
|
| | |
| | |
| | |
| | |
| | | |
this is part of our informal style guide, lets make it formal since
clearly its not getting followed very well.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Extend service resource to support systemd user services
|
| | | | |
|
| | | | |
|
| | | | |
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `preferred_manifest_record` function pretty prints the list of
existing files when the asked file can't be found. To do that, the root
path of the cookbook is removed from each existing file but the update
is done on the `existing_files` variable, not on a copy. When called
several times, this variable will eventually be equals to `[nil]`,
leading to a NoMethodError.
Without the fix, the new unit test fails with
> expected Chef::Exceptions::FileNotFound, got #<NoMethodError: undefined method `[]' for nil:NilClass> with backtrace:
> # ./lib/chef/cookbook_version.rb:321:in `block in preferred_manifest_record'
> # ./lib/chef/cookbook_version.rb:319:in `map!'
> # ./lib/chef/cookbook_version.rb:319:in `preferred_manifest_record'
> # ./spec/unit/cookbook_version_file_specificity_spec.rb:318:in `block (3 levels) in <top (required)>'
> # ./spec/unit/cookbook_version_file_specificity_spec.rb:317:in `block (2 levels) in <top (required)>'
Fixes #2561.
|
|\ \ \
| | | |
| | | | |
Autofixing new Perf cops in 0.37.2
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6 Performance/Casecmp
18 Performance/Detect
1 Performance/RangeInclude
27 Performance/RedundantBlockCall
6 Performance/RedundantMatch
5 Performance/RedundantMerge
18 Performance/StringReplacement
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
better chef+ruby rspec constraints
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
lets us use Gem::Dependency constraints directly as rspec
constraints for matching Chef::Version and RUBY_VERSION.
copies some magic sauce from bundler that does something
similar
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Data bag item hash can have name key
|
| |/ / / / |
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
RFC-060 gem metadata MVP
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
Clearer exception for loading non-existent data bag items in solo mode.
|