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)?
> >> 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).
--
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.
