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.
* The process should never, ever affect local system state (and thus could run
on a central server)
* 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
>>>> I've been planning on experimenting with making a similar effort
>> for
>>>> databases - that is, treating an individual database as a "device"
>>>> that can't run puppetd. People give me funny looks whenever I talk
>>>> about it, but IMO it's just as reasonable to think of a database as
>>>> being equivalent to a VM running on a host OS. You don't try to
>>>> manage the users inside of a VM from the host OS; why would you try
>>>> to manage the users inside of a database from outside the database?
>>>
>>> This makes perfect sense.
>>>
>>>> In either of these cases, having the expectation that all resources
>>>> use the same connection to the device you're managing might gain you
>>>> some efficiency wins, such as being able to use a cached connection
>>>> for all DB operations, or being able to prefetch the entire Cisco iOS
>>>> configuration rather than prefetching per resource types.
>>>
>>> Which is almost already what I'm doing (or at least it was as I was
>>> thinking) thanks to provider prefetching.
>>>
>>>> What do you think?
>>>
>>> That's an interesting view. I understand the appeal.
>>> I'm a bit skeptical about the puppet device app, and it's still unclear
>>> how you'd configure puppetd to fetch devices catalog along with the host
>>> catalog (I'm really not sure about your device resource).
>>>
>>> Can you elaborate about how you'd see the puppetd multiple run stuff,
>>> both in terms of configuration/UI and code?
>>> That's certainly something I can work on as a preamble patch to the
>>> cisco one.
>>
>> My whole point is that you wouldn't have a 'host' catalog per se - in
>> the simplest case (that is, the one involving no further
>> applications), you just do something like:
>>
>> for device in switch1 router1; do
>> puppet agent --confdir /var/devices/$device --vardir /var/devices/$device
>> --certname $device
>> done
>>
>> It wouldn't matter where you ran this, as long as it had access to
>> both the server and the device. The only caveat is that the 'facts'
>> would be for the proxy host, rather than the end device. This is one
>> of the things you'd want 'puppet device' to do - be able to extract
>> facts from a device.
>
> Oh, yes facts. I understand now the needs for the device puppet app.
>
>> Does that answer your questions? We're probably talking past each
>> other a bit here, since I can't quite see your confusion.
>
> Indeed :)
>
> I'll try to see how I can produce this device application and its config
> file (ie the place where you configure what device you aim to
> configure).
That would be awesome. Thanks.
--
Smoking is one of the leading causes of statistics. -- Fletcher Knebel
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
