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.
>> 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.
Does that answer your questions? We're probably talking past each other a bit
here, since I can't quite see your confusion.
--
It's not to control, but to protect the citizens of Singapore. In our
society, you can state your views, but they have to be correct.
-- Ernie Hai, co-ordinator of the Singapore Government
Internet Project
---------------------------------------------------------------------
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.
