Hi all,
I had a bit of time to research the existing device code to see if I can
use it for an integration with two specific use cases:
1. discovery/inventory - access hardware inventory and store it somewhere
where it can be retrieved.
So far, device supports this use case.
- specify a list of device endpoints in device.conf
- run puppet device to get their facts to serve as inventory (although
puppet device looks like it gets facts and requests catalogs, I will
probably call the facts method directly to just get the facts)
- have the front end query these facts from PuppetDB
2. management - manage the process of bringing up a cluster from scratch
This is the use case where puppet device is problematic.
In this use case, an external system needs to specify how a collection of
resources should be configured. The types of these resources are
heterogeneous, for example:
- Server
- Storage
- Network
- add Port
- create server
These hardware configuration rules (and their dependencies) map pretty
cleanly to the Puppet DSL and the Resource/Graph model. Where a manifests
represents multiple devices and multiple endpoints.
I had the following issues with puppet device for this use case:
1. It iterates through the endpoints and configures them one at a time
This is probably the biggest barrier. I need to keep track of a collection
of resources that target multiple endpoints and apply them in a certain
order. Looking at the device code it seems to just iterate through the
endpoints in device.conf and configure them one at a time.
I spent some time thinking about the current device command and how I might
use it to configure workflows across multiple endpoints.
- on the puppet master, keep a queue (or list) for each endpoint that needs
to be configured
- have an external process (the dispatcher) that keeps track of the
configuration that needs to be applied (along with their endpoints) and
stores the resources that represent that configuration into the correct
queue for it's endpoint.
- have an ENC that checks the certname of a device when it checks in, maps
it to a queue, and clears all entries for a queue (for it to apply)
- If the dispatcher keeps track of all of the resources that it put onto
which queue, it can track the report for those devices to know when it's
entire job is completed.
The above explanation is the best way I could think of to use the existing
device, but it is cumbersome enough that it warrants not using the device
model.
2. it does not allow for the specification of dependencies between multiple
device endpoints. It only allows for certain endpoints to be processed in a
certain order.
This is pretty much the same as #1, but worth mentioning separately.
3. It invents its own command line for doing things (it does not cleanly
operate with puppet resource, puppet apply, puppet agent with represents a
major loss of functionality)
4. Management of device.conf
The existence of device.conf creates its own management issues. You need to
assign a single node to a single device, you have to manage the process for
getting the credentials to that device, you have to figure out how many
devices/which devices go to which nodes as you scale out to a large number
of device endpoints.
*Solution:*
The transport model (as created by Nan Liu) seems to get around the issues
mentioned above and would allow a pretty clean integration path.
For folks not familiar with the transport model. It uses regular types and
providers that accept a parameter called transport that can be used to
indicate that it should be applied against some remote endpoint.
For example:
Transport { 'ssh':
url => some_url
password => 'some_password'
}
port {
transport => Transport[ssh]
}
This will work perfectly for my use case.
*The problem:*
This is fundamentally incompatible with the device model. I will not be
able to leverage resources implemented using this model, people using the
device model will not be able to leverage resources that I/we write.
I would feel much more confident in transport if it was possible to still
leverage the logic encoded in Puppet devices. This is impossible b/c
devices label themselves in such a way that means that they can only be
consumed by the puppet device command (while I would use resource, apply,
and agent).
Is this something we could just fix in the device type and providers? To
have them either get their credentials from device.conf or transport
resources? Could we get rid of the code that allows for puppet devices to
only be applied using the puppet device command?
Thanks for everyone that has made it this far in the email :) I look
forward to some great discussions!
- Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CA%2B0t2Ly_sdATdWOqTenqqKkyzgZR9WeOq5QLOhSM4008t2PFtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
