| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \
| |/ / /
|/| | | |
Style/NumericPredicate comparison style
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Apparently rubocop thinks the default behavior should be that we have to
rewrite every use of `foo == 0` into `foo.zero?` which is a big pile of
NOPE for me. After discovering that `.zero?` is actually slower, I'd
prefer to go the other direction. Same for `positive?` and
`negative?`.
These are the only uses of `zero?` in the chef/chef codebase, while I'm
pretty sure the inverse rule would touch nearly every file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
|\ \ \
| | | |
| | | | |
formally deprecate run_command
|
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
remove chef-provisioning-aws from travis
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
again IDK what is breaking travis
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
IDK why it is failing
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
blocks testing on ruby 2.4
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|/ / /
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
|\ \ \
| |/ /
|/| | |
[cheffs] Don't iterate parent object on exist? call
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, this code determined if an object existed by doing the
following:
parent.children.any? { |child| child.api_child_name == api_child_name }
For organizations and object types with a small number of total objects,
this wasn't problematic; however, it has very bad worst-case behavior.
For example, if a user was attempting to restore an organization with
30k client records to an empty organization, each client upload would do
the following:
1. Run GET /clients
2. Iterate the list returned in (1) normalizing the clients names along
the way.
3. Upload the client via POST when exist? returned false.
When the clients don't exist, this means step (2) will always iterate
over every member returned in step (1). By the time you get into the
1000s of clients, this iteration dominates the running time of the
process. For instance, consider the following ruby profile data:
Measure Mode: wall_time
Thread ID: 16939380
Fiber ID: 22163920
Total: 109.860468
Sort by: self_time
%self total self wait child calls name
26.83 29.475 29.475 0.000 0.000 500 <Class::IO>#select
8.60 38.876 9.446 0.000 29.430 464125 <Class::Chef::ChefFS::PathUtils>#join
7.02 12.226 7.717 0.000 4.509 928750 Chef::ChefFS::FileSystem::ChefServer::RestListEntry#api_child_name
6.79 7.459 7.459 0.000 0.000 930250 String#gsub
5.31 5.834 5.834 0.000 0.000 2320625 <Class::Chef::ChefFS::PathUtils>#regexp_path_separator
3.33 3.654 3.654 0.000 0.000 500 OpenSSL::X509::Store#set_default_paths
3.28 42.482 3.606 0.000 38.876 464125 Chef::ChefFS::FileSystem::BaseFSObject#initialize
2.95 3.244 3.244 0.000 0.000 930250 <Class::File>#extname
2.29 48.421 2.513 0.000 45.908 483375 *Class#new
38 wall clock seconds spent in PathUtils.join (part of the name
normalization during the list walk)
Note, an alternative might be to skip the exist? check completely,
opting to blindly POST and then rescuing the 409 and retry with a PUT.
Experimentation shows that PathUtils.join can also be improved
substantially; however, I'll leave those for a follow-up PR.
Signed-off-by: Steven Danna <steve@chef.io>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
chef/adamleff/ipo-500/fix-data-collector-org-parsing
Fix Data Collector organization parsing regex
|
| | |
| | |
| | |
| | | |
Signed-off-by: Adam Leff <adam@leff.co>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The regex used to pluck the Chef Server Organization from the
chef_server_url config value did not permit hyphens in org names
even though they are allowed by Chef Server. This caused org names
to get incorrectly truncated when sending the payload to Data
Collector servers.
Re: Chef bug IPO-500
Signed-off-by: Adam Leff <adam@leff.co>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Swap rbx testing in Travis for Ruby head
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
rbx is failing to install in travis as rvm wants to install via binary
and there isn't a binary install available. Swap for Ruby head instead
so we can test on Ruby 2.4
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Bump minor version to 12.18
|
|/ / /
| | |
| | |
| | | |
Signed-off-by: Scott Christopherson <scott@chef.io>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Dont fail the version bump if changelog fails
|
|/ / /
| | |
| | |
| | | |
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Add multiple client/nodes knife delete to release notes
|
| | |
| | |
| | |
| | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
|
|\ \ \
| | | |
| | | | |
remove Chef::Platform::HandlerMap
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
seems like an entirely unnecessary level of indirection
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Ensure node.docker? returns boolean
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
Trivial change to ensure node.docker? returns either true or false.
Signed-off-by: Andrew Brown <andrew.j.brown@gmail.com>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Update Release Announcements; Keep Dockerfile up-to-date
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tom Duffield <tom@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The README on the Docker Hub page contains instructions on how to use
the image with kitchen-dokken.
Signed-off-by: Tom Duffield <tom@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tom Duffield <tom@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The build system passes in the necessary build arguments, buts its
beneficial to have the Dockerfile keep up to date with what the latest
stable version is in case people want to build their own.
Signed-off-by: Tom Duffield <tom@chef.io>
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
Update the release announcements to show how to pull in the latest
version of Chef using kitchen-dokken.
Signed-off-by: Tom Duffield <tom@chef.io>
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Use object ID when detected unprocessed Resources
In the Data Collector, when detecting unprocessed resources, a Set
was built up using the resource object itself as the Set element.
Internally, Set adds this to a Hash.
We allow users to create custom resources that could contain a property
named "hash" which in turn wires up a `#hash` instance method on the
Resource. Ruby expects object's `#hash` method to return a Fixnum that
it uses internally. So if a resource had a "hash" property that returned
a String, bad things happened.
With this change, we make our own Hash and use the resource's object ID
in the key so we don't have to worry about the resource's `#hash` method
getting called and throwing an exception. I will send up a separate
change that warns users when they choose a property name that is already
an existing method name.
Fixes #5565.
Signed-off-by: Adam Leff <adam@leff.co>
|
| | | |
|
|\ \ \
| | | |
| | | | |
Fixed minor UI issues with Chef's MSI.
|