On Mon, 2011-01-17 at 21:57 -0800, Luke Kanies wrote:
> On Jan 14, 2011, at 1:31 AM, Brice Figureau wrote:
>
> > Hi,
> >
> > It looks like I forgot to answer this e-mail :(
> >
> > On Fri, 2011-01-07 at 13:04 -0800, Luke Kanies wrote:
> >> On Jan 7, 2011, at 11:44 AM, Brice Figureau wrote:
> >>
> >>> On 07/01/11 19:13, Luke Kanies wrote:
> >> [...]
> >>>> Hi Brice,
> >>>>
> >>>> This is great work, and it's work I've been excited to see for a long
> >>>> time.
> >>>>
> >>>> One thing that's not clear to me from this -- would you ever expect
> >>>> to have a device's resources mixed in with a normal host's resources?
> >>>
> >>> Yes that's correct, because that was the simplest way to bring the
> >>> feature.
> >>>
> >>>> That is, would you expect to see a given host's catalog containing
> >>>> anything other than device resources for a single device? It looks
> >>>> like I could use this to have vlan resources configured on multiple
> >>>> devices, plus normal Unix resources in a completely unrelated host.
> >>>
> >>> You're right. They're just normal resources except they're remote.
> >>> In my view you'd just design one of your node close to the remote device
> >>> to manage it.
> >>>
> >>>> We've been talking about this a good bit internally, and one of the
> >>>> things I want to do with this kind of work (managing systems that
> >>>> can't run Puppet agents) is retain the idea that a given catalog is
> >>>> only ever for one device. This could be done right now using puppetd
> >>>> and just setting certname specially (and maybe configdir/vardir
> >>>> generally), so it's more of a conceptual discipline at this point.
> >>>
> >>> Yes, that's right, this feature can be emulated with a given certname.
> >>>
> >>>> In this model, you'd either have a single resource that defines how
> >>>> to connect with the device:
> >>>>
> >>>> device { $hostname: user => ..., pass => ..., }
> >>>>
> >>>> Or you'd create a special application that does this:
> >>>>
> >>>> $ puppet device --proto ssh --user <user> --pass <pass>
> >>>> cisco2960.domain.com
> >>>>
> >>>> Or something like that.
> >>>
> >>> I see where you're going :)
> >>>
> >>>> Do you think this kind of model makes sense? Is this basically how
> >>>> you were planning on using this work?
> >>>
> >>> This certainly make sense, but frankly I didn't think about it. I was
> >>> more concerned about the remote management than on the user interface of
> >>> the given feature.
> >>>
> >>> The problem with having a specific device daemon/app is that you'll then
> >>> have to run one daemon per managed device. This is certainly good for
> >>> reporting or such features, but would be awful in terms of resource
> >>> consumption.
> >>> We could do this in one puppetd run by asking for more than one catalog
> >>> (one for every "device" and one for the given node).
> >>
> >> It doesn't have to be one process per device - you could have 'puppet
> >> device' (or whatever -- maybe 'proxy'?) take a list of names, or take
> >> a search string to use against Dashboard, or just about anything.
> >> Heck, it could be a long-running process that had a schedule for each
> >> host, and either forked off or used a thread for each host.
> >
> > Don't you think it would be a clone of the puppet agent (in terms of
> > code)?
>
> It would be similar except:
>
> * The process should be able to reasonably handle N devices, where N
> >> 1.
Of course. But that could essentially be just a loop around the
configurer, driven by a configuration file (ie /etc/puppet/device.conf)
(and see below for a more complete description of this idea).
> * The process should never, ever affect local system state (and thus
> could run on a central server)
That's correct, and that's not what the current version of this patch
does (which is wrong).
> * You could do more interesting things with the providers and such if
> you knew that all resources were only for that one kind of device and
> device instance
Here's how I see the puppet device system:
1) We have a (central) device configuration file. This should help us
map certnames to device urls (this could later on be stored elsewhere,
like the dashboard or anything else).
The format could be:
[device.domain.com]
type = cisco
url = ssh://user:[email protected]/?enable=enablepassword
...other devices...
I'm mentioning "type" here, but this could also be stored in the
manifests by using explicitely a provider.
2) Puppet device is responsible for parsing this file, and for each
device:
* use the device certname as our current $certname
* switch $vardir (and other essential state directory settings) to
$vardir/devices/$certname, creating those if they don't exist at the
same time.
* it should set the facts terminus to :device which would route the
configurer fact request to the correct terminus for the given device
type/model.
* call the configurer to fetch a catalog and apply it to the remote
device. Since $vardir is overriden, all the state goes to a different
directory.
* clean-up the mess we did with overriding $vardir
* wash, rinse, repeat for the next device.
This should partially isolate the current host from the device system
(at least the puppet internal stuff).
Now, I don't really see how we can achieve a perfect isolation. Nothing
can prevent someone to add a destructive file{} resource to the device
catalog, which unfortunately will be applied as is. Or maybe we can use
some kind of catalog filtering and allow only the network device
types...
This (even partial) isolation has the benefits of bringin proper device
facts, and reports/catalogs will be correctly fetched/pushed for the
given device certname.
In my view puppet device would not be a daemon, but that should be
something that can be added. I don't exactly remember how the agent is
used, I'll have to check that, though.
Does it match what you were thinking?
There is still something that I find clumsy or not following the "puppet
way". Until now every type was able to autodiscover the correct provider
(or can be forced to a given provider). We'll currently lose this model,
if we specify the device type in the config file.
Thanks,
--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
