Thanks for taking the time to answer my questions.
It seems like Puppet isn't the right tool for what I want to accomplish or
I will have to wait for native full featured Cisco support.
I think my confusion came from the notion that extending puppet in this way
was a simple end usery task.
I thought, for example, if I wanted to push out an EIGRP message digest
configuration (currently puppet device can't do this out of the box) I
could plug in my own code/ios commands *somewhere *and refer to it in my
module the same way I do other "resources'" like this (sloppy pseudo code):
keychain {
name => chainName
keynumber => 5
key-string => zzzzzzzz
}
interface {
'GigabitEthernet 0/1':
description => $interface_description_lan
eigrp keychain {
as => 123
name => chainName
}
}
But, if I understand what you are saying, that would require a great deal
of coding. Being that I am not a ruby dev this would probably be a waste
of my time.
On Tuesday, December 22, 2015 at 10:02:59 AM UTC-5, jcbollinger wrote:
>
>
>
> On Monday, December 21, 2015 at 12:30:16 PM UTC-6, red 888 wrote:
>>
>> Thanks for replying!
>>
>> I'm aware of how puppet device works and I know there is no actual agent
>> software running on the Cisco device (I'm not talking about the newer OnePK
>> thing).
>>
>> My question was how can I use this to send my own commands in a
>> integrated way- meaning the same way Puppet Device does it.
>>
>
>
> There is nothing particularly magical about 'puppet device'. It relies on
> the same Puppet infrastructure as the agent, and in fact, it seems mostly
> to be just a specialization of the agent. The "integrated way" in which
> 'puppet device' delivers commands to network devices is not directly
> accessible at the DSL level. It is an aspect of the Ruby implementations
> of the providers for the resource types managed by that mechanism.
>
>
>
>>
>> "You could, however, use an Exec to open a telnet or ssh connection to
>> the router with which to execute a remote command; *that is akin to how
>> the built-in device management types work*"
>>
>> Opening my own instance of telent/ssh defeats the purpose- I want to do
>> it "how the built-in device management" feature does it. Meaning I have
>> already defined the IPs and authentication info for my routers in
>> device.conf and I don't want to have to hard code that info into the module.
>>
>
>
> I don't see where hard-coding data into your module comes in. Pretty much
> no one wants to do that; instead they externalize and centralize their
> data. You could, too.
>
> But if you are serious about using *the same* infrastructure that the
> providers for the existing resource types use, then you are talking about
> writing a custom type and provider -- a remote analog of Exec. That is a
> significant undertaking, especially considering that the goal is something
> that must fit even more poorly into the Puppet model than does Exec
> itself. If you want to pursue this course anyway, then the Puppet
> Developers <https://groups.google.com/forum/#!forum/puppet-dev> group
> would be a more appropriate place to discuss the details. Most of those
> folks participate here, too, but they're more likely to notice your
> question. Before you go there, however, you should read the Custom Type
> documentation <https://docs.puppetlabs.com/guides/custom_types.html> and
> study, say, the current implementation of the Interface resource type and
> its provider to get oriented to the task.
>
> You should also consider whether you really need Puppet to issue
> *arbitrary* commands to your routers. Puppet is fundamentally a
> state-management service, and it works best when used that way. If you can
> characterize the objective of the IOS commands you want to run in terms of
> managing some aspect of the state of the device, especially an aspect whose
> value can be not only twiddled but examined, then it would probably be both
> easier and better to achieve that objective by adding a property to one of
> the existing resource types used by 'puppet device'. Of course, I would
> suggest doing that in the context of a feature request.
>
>
>
>>
>> Puppet device already has that telnet/ssh connection info so how can I
>> send the devices my own arbitrary commands from my module?
>>
>>
>
> Well no, it's not 'puppet device' itself that has that (I don't think),
> it's the providers for the custom types involved. There are no hooks for
> it in the DSL, but as I said, you could write your own custom type, with a
> provider that uses the same Ruby support base.
>
>
>
>> Is there a way I can refer to the telnet session/connection in my module
>> and just enter my own commands?
>>
>>
>
> Not without first writing a pile of Ruby code to make it possible, no.
>
> It is perhaps appropos to observe at this point, as I have at times in the
> past, that Puppet is not a script engine. Puppet DSL has some script-like
> characteristics, but its role is solely to describe how to build catalogs;
> the agent never sees DSL. For their part, Puppet catalogs are not scripts,
> nor script analogues: they are *data*. The Puppet agent -- or its
> special-purpose analog, 'puppet device' -- uses catalog data and its own
> configuration to determine what actions to perform. Therefore, if you want
> one of those Puppet services to manage a particular piece of state for you
> then you must convey that request by causing appropriate resources to be
> included in the target node's catalog. If there is no existing resource
> type by which you can describe what you want, then you need to create one.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ffa3279c-5613-4c2b-9954-7fd2d66d9a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
