You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+43-45Lines changed: 43 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -176,37 +176,6 @@ The generated unit tests in `spec/unit/puppet/provider/foo_spec.rb` get automati
176
176
177
177
Support for remote resources is enabled through a `transport` class. A transport class contains the code for managing connections and processing information to and from the remote resource. For information on how to create a transport class, see the [Resource API specification](https://github.com/puppetlabs/puppet-specifications/tree/master/language/resource-api#transport).
178
178
179
-
### `puppet device` support
180
-
181
-
To connect to a remote resource through `puppet device`, you must call a `transport` class through a device shim to maintain compatibility with Puppet Resource.
182
-
183
-
A `device` class is created that Puppet Resource will call, however this will inherit from the `transport` class which will contain the following methods (as detailed in the [Resource API specification](https://github.com/puppetlabs/puppet-specifications/tree/master/language/resource-api#transport)):
184
-
*`initialize`
185
-
*`verify`
186
-
*`facts`
187
-
*`connect`
188
-
189
-
For example, the `device` class will be a pass through to `transport`:
This requires a `transport` class and schema, as detailed in the [Resource API specification](https://github.com/puppetlabs/puppet-specifications/tree/master/language/resource-api#transport).
209
-
210
179
An example of a transport class:
211
180
212
181
```ruby
@@ -215,17 +184,17 @@ module Puppet::Transport
215
184
# The main connection class to a PAN-OS API endpoint
216
185
classDeviceType
217
186
definitialize(context, connection_info)
218
-
# Initialization eg. validate connection_info
187
+
# Initialization eg. validate connection_info
219
188
end
220
-
189
+
221
190
defverify(context)
222
191
# Test that transport can talk to the remote target
Please note that within the transport schema, the following keywords are reserved words:
274
243
275
-
######Usable within the schema
276
-
244
+
#### Usable within the schema
245
+
277
246
The following keywords are encouraged within the Transport schema:
278
-
247
+
279
248
*`uri` - Use when you need to specify a specific URL to connect to. All of the following keys will be computed from the `uri` if possible. In the future more url parts may be computed from the URI as well.
280
-
*`host` - Use to specify and IP or address to connect to.
249
+
*`host` - Use to specify and IP or address to connect to.
281
250
*`protocol` - Use to specify which protocol the transport should use for example `http`, `https`, `ssh` or `tcp`
282
251
*`user` - The user the transport should connect as.
283
252
*`port` - The port the transport should connect to.
284
-
285
-
######Non-Usable within the schema
286
-
253
+
254
+
#### Non-Usable within the schema
255
+
287
256
The following keywords are keywords that must not be used by the transport schema:
288
-
257
+
289
258
*`name` - transports should use `uri` instead of name.
290
259
*`path` - reserved as a uri part
291
260
*`query` - reserved as a uri part
292
261
*`run-on` - This is used by bolt to determine which target to proxy to. Transports should not rely on this key.
293
262
*`remote-transport` - This is used to determine which transport to load. It should always be the transport class name "declassified".
294
263
*`remote-*` Any key starting with `remote-` is reserved for future use.
295
-
264
+
296
265
Note: Currently bolt inventory requires that a name be set for every target and always uses that name as the URI. This means there is no way to specify `host` separately from the host section of the `name` when parsed as a URI.
297
266
298
267
After the device class, transport class and transport schema have been implemented, `puppet device` will be able to use the new provider, and supply it (through the device class) with the URL specified in the [`device.conf`](https://puppet.com/docs/puppet/5.3/config_file_device.html).
@@ -301,6 +270,35 @@ After the device class, transport class and transport schema have been implement
301
270
302
271
To allow modules to deal with different backends independently, the Resource API implements a mechanism to use different API providers side by side. For a given transport/device class (see above), the Resource API will first try to load a `Puppet::Provider::TypeName::<DeviceType>` class from `lib/puppet/provider/type_name/device_type.rb`, before falling back to the regular provider at `Puppet::Provider::TypeName::TypeName`.
303
272
273
+
### `puppet device` support
274
+
275
+
To connect to a remote resource through `puppet device`, you must call a `transport` class through a device shim to maintain compatibility with Puppet Resource.
276
+
277
+
A `device` class is created that Puppet Resource will call, however this will inherit from the `transport` class which will contain the following methods (as detailed in the [Resource API specification](https://github.com/puppetlabs/puppet-specifications/tree/master/language/resource-api#transport)):
278
+
*`initialize`
279
+
*`verify`
280
+
*`facts`
281
+
*`connect`
282
+
283
+
For example, the `device` class will be a pass through to `transport`:
The [Resource API](https://github.com/puppetlabs/puppet-specifications/blob/master/language/resource-api/README.md) describes details of all the capabilities of this gem.
0 commit comments