On Thu, Dec 12, 2013 at 12:08 AM, Markus Burger
<[email protected]>wrote:
> Hi,
>
> On 11-12-2013 10:51:08, Dan Bode wrote:
> > 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 currently use a simple solution to work around this problem where
> i create the device.conf through an external process on the fly and
> specify my
> devices and there dependencys in a yaml file, run them in order and just
> check the exit code.
>
> it looks something like this:
>
> ---
> defaults:
> scheme: sshios
> port: 22
> userinfo: foo:bar
> query: crypt=true
> cmd: /usr/bin/puppet device --verbose --environment=network
> --detailed-exit-codes --deviceconfig={{DEVCFG}} || [ $? -eq 2 ]
>
> devices:
> dc1:
> sw-dc1-01.foo.bar:
> deps:
> - *
> sw-dc1-02.foo.bar:
> sw-dc1-03.foo.bar:
> deps:
> - sw-dc1-02.foo.bar
> str-dc1-01.foo.bar:
> scheme: netapp
> deps:
> - sw-dc1-01.foo.bar
>
>
> >
> > 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.
>
> Can you point me to a thread where this was discussed ?
> I can only see an advantage of the purposed model for certain
> situations / device types but not for the traditional use case.
There was some discussion related to this here:
https://groups.google.com/d/msg/puppet-users/cT-9wYquDV8/BkdhJsxqv8gJ
I think my view point is why not manage all API as a resource? What about
database? dynamic DNS records? I think this opens some interesting options
v.s. a silo config restricted to some box. If you want puppet device style
of isolated puppet run you can achieve it with puppet agent/transport:
node network_device_name {
transport { 'f5':
username => 'admin',
password => 'pass',
}
F5_resource {
transport => Transport['f5'],
}
...
}
# This gets the catalog specific resource for node 'network_device_name'
{...}, which is really the same as puppet device with 'network_device_name'
in device.conf:
puppet agent --certname <network_device_name>
Nan
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACqVBqCU2Acrna%3DWz_z1kmbBYH4wbNv-VEiaj9xetSq9ToPTVw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
