cheffish 1.2 → 1.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +116 -3
- data/lib/cheffish/chef_run_listener.rb +4 -2
- data/lib/cheffish/version.rb +1 -1
- metadata +3 -4
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: fd1d356ff0bdaa2531dbf85e2b390ed4396e6527
|
4
|
+
data.tar.gz: 0e7990d44ec9ac64be668886c2efd8973989339e
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: a3d065506dc7daf38dee52868720169f0018af70343a51375d8271eb3c783a4006ce82104a2133806797e5a7af20e98cb77f24fb12f0e863fe94b8fbcb1842e2
|
7
|
+
data.tar.gz: 48c43f52ae0e79a2951640128d4f9040b8f8905b4c702380fb3690fe43399c2929a2177a1661af04b4200bcc8b40dc2b3fc78b70a975f119b880d04fd2d0cee9
|
data/README.md
CHANGED
@@ -1,4 +1,117 @@
|
|
1
|
-
Cheffish
|
2
|
-
========
|
1
|
+
# Cheffish
|
3
2
|
|
4
|
-
This library
|
3
|
+
This library provides a variety of convergent resources for interacting with the Chef Server; along the way, it happens to provide some very useful and sophisticated ways of running Chef resources as recipes in RSpec examples.
|
4
|
+
|
5
|
+
**This document may have errors, but it should have enough pointers to get you oriented.**
|
6
|
+
|
7
|
+
There are essentially 3 collections here:
|
8
|
+
|
9
|
+
## Resource/Provider Pairs for Manipulating Chef Servers
|
10
|
+
|
11
|
+
You'd use these in recipes/cookbooks. They are documented on the [main Chef docs site](https://docs.chef.io).
|
12
|
+
|
13
|
+
- [chef_acl](https://docs.chef.io/resource_chef_acl.html)
|
14
|
+
- [chef_client](https://docs.chef.io/resource_chef_client.html)
|
15
|
+
- [chef_container](https://docs.chef.io/resource_chef_container.html)
|
16
|
+
- [chef_data_bag](https://docs.chef.io/resource_chef_data_bag.html)
|
17
|
+
- [chef_data_bag_item](https://docs.chef.io/resource_chef_data_bag_item.html)
|
18
|
+
- [chef_environment](https://docs.chef.io/resource_chef_environment.html)
|
19
|
+
- [chef_group](https://docs.chef.io/resource_chef_group.html)
|
20
|
+
- [chef_mirror](https://docs.chef.io/resource_chef_mirror.html)
|
21
|
+
- [chef_node](https://docs.chef.io/resource_chef_node.html)
|
22
|
+
- [chef_organization](https://docs.chef.io/resource_chef_organization.html)
|
23
|
+
- [chef_resolved_cookbooks](https://docs.chef.io/resource_chef_resolved_cookbooks.html)
|
24
|
+
- [chef_role](https://docs.chef.io/resource_chef_role.html)
|
25
|
+
- [chef_user](https://docs.chef.io/resource_chef_user.html)
|
26
|
+
- [private_key](https://docs.chef.io/resource_private_key.html)
|
27
|
+
- [public_key](https://docs.chef.io/resource_public_key.html)
|
28
|
+
|
29
|
+
## Base/Helper Classes
|
30
|
+
|
31
|
+
To support the resource/provider pairs.
|
32
|
+
|
33
|
+
|
34
|
+
## RSpec Support
|
35
|
+
|
36
|
+
Most of these RSpec...things were developed for testing the resource/provider pairs above; *however*, you can also `require cheffish/rspec/chef_run_support` for any RSpec `expect`s you'd like, as we do for `chef-provisioning` and its drivers (especially `chef-provisioning-aws`).
|
37
|
+
|
38
|
+
The awesomeness here is that instead of instantiating a `run_context` and a `node` and a `resource` as Ruby objects, you can test your resources in an actual recipe:
|
39
|
+
|
40
|
+
```ruby
|
41
|
+
when_the_chef_12_server "exists", organization: 'some-org', server_scope: :context, port: 8900..9000 do
|
42
|
+
file "/tmp/something_important.json" do
|
43
|
+
content "A resource in its native environment."
|
44
|
+
end
|
45
|
+
end
|
46
|
+
```
|
47
|
+
|
48
|
+
An enclosing context that spins up `chef-zero` (local mode) Chef servers as dictated by `server_scope`. `Chef::Config` will be set up with the appropriate server URLs (see the `with_*` operators below).
|
49
|
+
|
50
|
+
`server_scope`:
|
51
|
+
- `:context`
|
52
|
+
- `:example` *[default?]*
|
53
|
+
- ?
|
54
|
+
|
55
|
+
`port`:
|
56
|
+
- port number (8900 is the default)
|
57
|
+
- port range (server will continue trying up this range until it finds a free port)
|
58
|
+
|
59
|
+
```ruby
|
60
|
+
expect_recipe {
|
61
|
+
# unquoted recipe DSL here.
|
62
|
+
}.to be_truthy # or write your own matchers.
|
63
|
+
```
|
64
|
+
|
65
|
+
Converges the recipe using `expect()` (parentheses), which tests for a value and **cannot** be used with `raise_error`.
|
66
|
+
|
67
|
+
```ruby
|
68
|
+
expect_converge {
|
69
|
+
# unquoted recipe DSL here.
|
70
|
+
}.to raise_error(ArgumentException)
|
71
|
+
```
|
72
|
+
|
73
|
+
Converges the recipe using `expect{ }` (curly brackets), which wraps the block in a `begin..rescue..end` to detect when the block raises an exception; hence, this is **only** for `raise_error`.
|
74
|
+
|
75
|
+
The blocks for the following appear to be mostly optional: what they actually do is set the `Chef::Config` variable in the name to the given value, and if you provide a block, the change is scoped to that block. Probably this would be clearer if it were aliased to (and preferring) `using` rather than `with`.
|
76
|
+
|
77
|
+
- with_chef_server(server_url, options = {}, &block)
|
78
|
+
- with_chef_local_server(options, &block)
|
79
|
+
- with_chef_environment(name, &block)
|
80
|
+
- with_chef_data_bag_item_encryption(encryption_options, &block)
|
81
|
+
- with_chef_data_bag(name)
|
82
|
+
- Takes a block, though this is not noted in the method signature.
|
83
|
+
|
84
|
+
|
85
|
+
|
86
|
+
get_private_key(name)
|
87
|
+
|
88
|
+
|
89
|
+
### RSpec matchers
|
90
|
+
|
91
|
+
These are used with `expect_recipe` or `expect_converge`:
|
92
|
+
|
93
|
+
```ruby
|
94
|
+
expect_recipe {
|
95
|
+
file "/tmp/a_file.json" do
|
96
|
+
content "Very important content."
|
97
|
+
end
|
98
|
+
}.to be_idempotent.and emit_no_warnings_or_errors
|
99
|
+
```
|
100
|
+
|
101
|
+
`be_idempotent`
|
102
|
+
|
103
|
+
- Runs the provided recipe *again* (`expect_(recipe|converge)` ran it the first time) and asks the Chef run if it updated anything (using `updated?`, which appears to be defined on `Chef::Resource` instead of `Chef::Client`, so there's some clarification to be done there); the matcher is satisfied if the answer is "no."
|
104
|
+
|
105
|
+
|
106
|
+
`emit_no_warnings_or_errors`
|
107
|
+
|
108
|
+
- Greps the Chef client run's log output for WARN/ERROR lines; matcher is satisfied if there aren't any.
|
109
|
+
|
110
|
+
`have_updated`
|
111
|
+
|
112
|
+
- Sifts the recipe's event stream(!) to determine if any resources were updated; matcher is satisfied is the answer is "yes."
|
113
|
+
- This is *not* the opposite of `be_idempotent`.
|
114
|
+
|
115
|
+
`partially_match`
|
116
|
+
|
117
|
+
- TBD
|
@@ -20,8 +20,10 @@ module Cheffish
|
|
20
20
|
|
21
21
|
def disconnect
|
22
22
|
# Stop the servers
|
23
|
-
node.run_context
|
24
|
-
server
|
23
|
+
if node.run_context
|
24
|
+
node.run_context.cheffish.local_servers.each do |server|
|
25
|
+
server.stop
|
26
|
+
end
|
25
27
|
end
|
26
28
|
end
|
27
29
|
end
|
data/lib/cheffish/version.rb
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: cheffish
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version:
|
4
|
+
version: 1.2.1
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- John Keiser
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date: 2015-
|
11
|
+
date: 2015-07-17 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: chef-zero
|
@@ -163,9 +163,8 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
163
163
|
version: '0'
|
164
164
|
requirements: []
|
165
165
|
rubyforge_project:
|
166
|
-
rubygems_version: 2.4.
|
166
|
+
rubygems_version: 2.4.7
|
167
167
|
signing_key:
|
168
168
|
specification_version: 4
|
169
169
|
summary: A library to manipulate Chef in Chef.
|
170
170
|
test_files: []
|
171
|
-
has_rdoc:
|