| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Give more details on why people are seeing these problems so they can fix them.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reset the global resource and provider handler maps before each and
every test.
note that mutation through the top-level keys will get preserved so
this is not perfect, but deep-duping through every single test we run
becomes expensive.
this is sufficient to flush out the global state of all the test lwrp fixtures
that we setup.
it discovered several usage bugs where we either relied on this feature
or where we were testing different fixtures from the ones we thought we
were.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Chris Arnold <cma.arnold@gmail.com>
|
| |
|
|
|
|
|
| |
This forces everyone to starting using new_resource.property_name
instead of just property_name.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
| |
|
|
|
|
|
|
| |
this also deprecates the multi-resource notification syntax where
`foo[a,b]` would attempt to notify both `foo[a]` and `foo[b]` because
that is hella ambiguous.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes nameless resources work in the DSL:
```ruby
apt_update
```
It does it by giving it an empty-string name of ""
It also drops support for multi-arg resources, that has been deprecated
for some time:
```ruby
some_resource "foo", "bar", "baz"
```
Note that multipackage package resources do not use multiple args, but a
single argument which is an arry:
```ruby
package [ "lsof", "strace", "tcpdump" ]
```
So this change does not affect that usage. Multi-arg has been
deprecated for some time now and its not clear that it was ever used by
anyone.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
I think this nukes descendants tracker, although might need to clean it
up in a few more spots.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old action_class code was doing some magical stuff with the provider
accessor in order to determine if the class was supposed to be a custom
resource or not and have the action_class autovivifying accessor return nil
in cases when the resource wasn't a custom resource and implementing
inheritance by walking back up the tree in ways that were difficult to
grok.
This removes the magic from the provider so that there's no longer any
accessor that magically short-circuits to nil if the resource is not
supposed to be a custom resource.
There is now a simple inherited API for `Chef::Resource.custom_resource?`
which just defines if the class is a custom resource or not. Since both
`action` and `action_class` call `define_action_class` they both wind up
setting this boolean on the class, which is then inherited to subclasses
automatically, which eliminates the need to walk up the hierarchy.
The superclass.respond_to?(:action_class) checks have also been rendered
unnecessary by removing the code that walked up the inheritance
hierarchy and also because Chef::Resource is never going to be a
custom resource itself, so will never call `define_action_class` so from
inside of `define_action_class` you can always rely on the superclass
being a resource and implementing `custom_resource?` and `action_class`.
The wiring for picking the provider is now moved explicitly to the
ProviderResolver -- even though custom resources hardcode a 1:1
resource-to-provider mapping. This reads much clearer to me than the
magical wiring to the provider accessor off of the instance.
The bug that this fixes was that the way the magical accessor
nil-or-action_class was implemented the old way of defining action
helpers with class_eval broke:
```ruby
action_class.class_eval << EOM
def a
"foo"
end
EOM
```
If that came before any action_class-with-a-block or action declaration
and the resource did not inherit from another custom resource then the
action_class would not be created and it would return nil, which was an
API which the magical wiring in the provider accessor required.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
we did actually have tests around creating actions with spaces and
hyphens in their names. we had fallback code for properties, but it
was broken and threw a "private method define_resource called" and then
it created a closure and didn't have the `name` in the binding so it
called itself and blew up the stack.
this change walks that back. it does prove that we still support
UTF-8 in property names, actions and DSL names, which i'd argue is
more than enough.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
forgot to branch and need more coffee
This reverts commit 02ec917f9356d999c44aceb7f1ff43957b0fe832.
|
| |
|
|
|
|
|
| |
I think this nukes descendants tracker, although might need to clean it
up in a few more spots.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
Switch over the Chef-12.0 ProviderResolver is now completed.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
department of redundancy department
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |\
| |
| | |
Properly deprecate old Chef::Platform methods
|
| | |
| |
| |
| |
| |
| |
| |
| | |
These should have been deprecated formally in 12.5.1 after the
Dynamic Provider-Resolver'ing of the internal chef resources
was completed.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |/
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
probably also our best documentation on how to write accumulators right
now
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
(This was always intended to be the case, and it's difficult
to do it yourself. We have been teaching people whyrun-safe
methods to make resources right alongside Custom Resources, as well.)
|
| | |
|
| |
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This allows one to have a resource which is really only appropriate for
one platform, but available everywhere. Then you simply allow noop to
provide the resource everywhere besides where it's supposed to be.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
| |
'nil_set' parameter to get() to skip a spurious warning when that happens.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
| |
unless using properties on the resource
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(User will expect "x x" to grab the parent property.)
|
| |
|
|
| |
this reverts the focus and allows all the tests to run again
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
