On 07/01/11 19:13, Luke Kanies wrote:
> On Jan 3, 2011, at 1:32 PM, Brice Figureau wrote:
>
>> Hi,
>>
>> This is my Christmas Gift for the community :) That's something
>> that was haunting me for a long time: a way to manage
>> switch/routers directly from puppet. Unfortunately most of the
>> switches/routers don't run ruby natively and as such can't run
>> puppet.
>>
>> Based on an open-space discussion that happened at PuppetCamp EU in
>> May 2010, I finally managed to find the time to implement a
>> solution to this problem.
>>
>> This is currently a Proof Of Concept of a puppet type/provider
>> connecting to remote cisco switch/routers running ios to manage: *
>> interfaces (including ip address, trunking, etc...) * vlans
>>
>> This has been tested successfully on some cisco hardware I
>> happened to have available (a couple of switch and low-end
>> routers).
>>
>> The puppet provider can connect to remote switch/routers through
>> ssh and/or telnet.
>>
>> To manage an interface:
>>
>> interface { "FastEthernet 0/1": device_url =>
>> "ssh://user:[email protected]/", mode => trunk,
>> encapsulation => dot1q, trunk_allowed_vlans => "1-99,200,253",
>> description => "to back bone router" }
>>
>> or interface { "Vlan 1": device_url =>
>> "ssh://user:[email protected]/", description => "internal
>> net", ipaddress => [ "192.168.0.1/24", "fe08::/128 link-local"] }
>>
>> And to manage vlans: vlan { "99": description => "management",
>> device_url => "ssh://user:[email protected]/", }
>>
>> I didn't solve the uniqueness of the name of an interface yet
>> (currently it isn't possible to have 2 switches with the same
>> interface name, which is an issue).
>>
>> One possibility would be to use as interface name, the device_url.
>> If anyone has a better idea, let me know.
>>
>> If this patch proves to be a success, we can add more providers (ie
>> hp procurve, juniper routers, etc..) and more types (routers,
>> access lists, routing table entries, routing protocols, etc...).
>
> 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).
> 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.
Thanks,
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
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.
