Skip to content

Commit fa47385

Browse files
authored
Merge pull request #160 from willmeek/docs-update
(FM-7829) Update README with transports examples
2 parents e9731a9 + aae6604 commit fa47385

File tree

1 file changed

+116
-7
lines changed

1 file changed

+116
-7
lines changed

README.md

Lines changed: 116 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -172,19 +172,128 @@ The `create`/`update`/`delete` methods get called by the `SimpleProvider` base-c
172172

173173
The generated unit tests in `spec/unit/puppet/provider/foo_spec.rb` get automatically evaluated with `pdk test unit`.
174174

175-
### `puppet device` support
175+
## Remote resources
176176

177-
To support remote resources using `puppet device`, a few more steps are needed. First a `Puppet::Util::NetworkDevice::<device type>::Device` class needs to exist, which provides facts and connection management . That device class can inherit from `Puppet::Util::NetworkDevice::Simple::Device` to receive a simple default configuration parser using hocon.
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).
178178

179-
The provider needs to specify the `remote_resource` feature to enable the second part of the machinery.
179+
An example of a transport class:
180180

181-
After this, `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).
181+
```ruby
182+
# lib/puppet/transport/device_type.rb
183+
module Puppet::Transport
184+
# The main connection class to a PAN-OS API endpoint
185+
class DeviceType
186+
def initialize(context, connection_info)
187+
# Initialization eg. validate connection_info
188+
end
189+
190+
def verify(context)
191+
# Test that transport can talk to the remote target
192+
end
193+
194+
def facts(context)
195+
# Access target, return a Facter facts hash
196+
end
197+
198+
def close(context)
199+
# Close connection, free up resources
200+
end
201+
end
202+
end
203+
```
204+
205+
An example of a corresponding schema:
206+
207+
```ruby
208+
# lib/puppet/transport/device_type.rb
209+
Puppet::ResourceAPI.register_transport(
210+
name: 'device_type', # points at class Puppet::Transport::DeviceType
211+
desc: 'Connects to a device_type',
212+
# features: [], # future extension points
213+
connection_info: {
214+
host: {
215+
type: 'String',
216+
desc: 'The host to connect to.',
217+
},
218+
user: {
219+
type: 'String',
220+
desc: 'The user.',
221+
},
222+
password: {
223+
type: 'String',
224+
sensitive: true,
225+
desc: 'The password to connect.',
226+
},
227+
enable_password: {
228+
type: 'String',
229+
sensitive: true,
230+
desc: 'The password escalate to enable access.',
231+
},
232+
port: {
233+
type: 'Integer',
234+
desc: 'The port to connect to.',
235+
},
236+
},
237+
)
238+
```
239+
240+
### Transport Schema keywords
241+
242+
Please note that within the transport schema, the following keywords are reserved words:
182243

183-
#### Device-specific providers
244+
#### Usable within the schema
184245

185-
To allow modules to deal with different backends independently of each other, the Resource API also implements a mechanism to use different API providers side-by-side. For a given device type (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`.
246+
The following keywords are encouraged within the Transport schema:
247+
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.
249+
* `host` - Use to specify and IP or address to connect to.
250+
* `protocol` - Use to specify which protocol the transport should use for example `http`, `https`, `ssh` or `tcp`
251+
* `user` - The user the transport should connect as.
252+
* `port` - The port the transport should connect to.
253+
254+
#### Non-Usable within the schema
255+
256+
The following keywords are keywords that must not be used by the transport schema:
257+
258+
* `name` - transports should use `uri` instead of name.
259+
* `path` - reserved as a uri part
260+
* `query` - reserved as a uri part
261+
* `run-on` - This is used by bolt to determine which target to proxy to. Transports should not rely on this key.
262+
* `remote-transport` - This is used to determine which transport to load. It should always be the transport class name "declassified".
263+
* `remote-*` Any key starting with `remote-` is reserved for future use.
264+
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.
266+
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).
268+
269+
#### Transport/device specific providers
270+
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`.
272+
273+
### Puppet backwards compatibility
274+
275+
To connect to a remote resource through `puppet device`, you must provide a device shim to maintain compatibility with Puppet. The device shim needs to interface the transport to puppet's config and runtime expectations.
276+
277+
In the simplest case you can use the provided `Puppet::ResourceApi::Transport::Wrapper` like this:
278+
279+
```ruby
280+
# lib/puppet/util/network_device/device_type/device.rb
281+
282+
require 'puppet'
283+
require 'puppet/resource_api/transport/wrapper'
284+
# force registering the transport schema
285+
require 'puppet/transport/schema/device_type'
286+
287+
module Puppet::Util::NetworkDevice::Device_type
288+
class Device < Puppet::ResourceApi::Transport::Wrapper
289+
def initialize(url_or_config, _options = {})
290+
super('device_type', url_or_config)
291+
end
292+
end
293+
end
294+
```
186295

187-
### Further Reading
296+
## Further reading
188297

189298
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.
190299

0 commit comments

Comments
 (0)