Adding a new switch type to Puppet Device

[Greg Sutcliffe]

Hi all,

I guess this is mainly aimed at Brice, but feel free to chime in :)

I'm starting to implement Allied Telesis switches in puppet device, since we have a pressing need to control them properly. I've managed to get login and facts working, so I'm happy with my progress thus far, but I currently have two questions...

1) Is it possible to do this in a module, as per other type/provider updates? Currently I'm hacking on the puppet 2.7.3 gem on one of my clients, and that seems clunky. However, with changes in the util/ folder, I'm guessing it's not presently possible.

2) Assuming I can get my boss to permit me to put my work on Github (working on that :P), I guess this is the right place to get reviews and issue pull requests?

Cheers,

Greg

[Nan Liu]

On Mon, Sep 12, 2011 at 3:01 AM, Greg Sutcliffe
<greg.su...@gmail.com> wrote:
> Hi all,
> I guess this is mainly aimed at Brice, but feel free to chime in :)
> I'm starting to implement Allied Telesis switches in puppet device, since we
> have a pressing need to control them properly. I've managed to get login and
> facts working, so I'm happy with my progress thus far, but I currently have
> two questions...
> 1) Is it possible to do this in a module, as per other type/provider
> updates? Currently I'm hacking on the puppet 2.7.3 gem on one of my clients,
> and that seems clunky. However, with changes in the util/ folder, I'm
> guessing it's not presently possible.

Yes with some work around required. You need to export RUBYLIB with
the appropriate path. See example and known limitation section:
https://github.com/puppetlabs/puppetlabs-f5

In my limited experience, seems easier to dev/test with puppet
resource/puppet apply commands, just add apply_to_device to the
resource type when you are ready for full testing using puppet device
command.

> 2) Assuming I can get my boss to permit me to put my work on Github (working
> on that :P), I guess this is the right place to get reviews and issue pull
> requests?

Absolutely.

Thanks,

Nan

[Greg Sutcliffe]

On 12 September 2011 18:26, Nan Liu <n...@puppetlabs.com> wrote:
> Yes with some work around required. You need to export RUBYLIB with
> the appropriate path. See example and known limitation section:
> https://github.com/puppetlabs/puppetlabs-f5
>
> In my limited experience, seems easier to dev/test with puppet
> resource/puppet apply commands, just add apply_to_device to the
> resource type when you are ready for full testing using puppet device
> command.

Thanks Nan - seeing what others are doing to extend puppet device is
massively helpful. I'll be reading your code closely tomorrow :)

Cheers,
Greg

[Brice Figureau]

You'll see when reading Nan's code that the biggest difference in the
cisco and F5 stuff is the transport. The F5 provider Nan created uses
directly the F5 http API, because its better (and certainly easier) than
emulating a human typing commands through ssh :) like I did for the
cisco stuff.

That unfortunately shows that there are lots of differences between
network devices types/models. You'll certainly find that the assumptions
I did for cisco switch might not map cleanly your switch models.
Something I couldn't really do when implementing only cisco IOS was to
find and extract the commonalities between various device classes (both
in terms of types and providers).

I'm definitely interested in helping you implement those new models.
Feel free to ping me on irc (masterzen on #puppet and #puppet-dev) or
here if you need my help :) (and of course I'll be available live during
puppet conf to answer questions)
--
Brice Figureau
My Blog: http://www.masterzen.fr/

[Greg Sutcliffe]

On 12 September 2011 21:53, Brice Figureau

<brice-...@daysofwonder.com> wrote:
> You'll see when reading Nan's code that the biggest difference in the
> cisco and F5 stuff is the transport. The F5 provider Nan created uses
> directly the F5 http API, because its better (and certainly easier) than
> emulating a human typing commands through ssh :) like I did for the
> cisco stuff.

No doubt - although for Allied Telesis, I am also using telnet transport :)

> That unfortunately shows that there are lots of differences between
> network devices types/models. You'll certainly find that the assumptions
> I did for cisco switch might not map cleanly your switch models.
> Something I couldn't really do when implementing only cisco IOS was to
> find and extract the commonalities between various device classes (both
> in terms of types and providers).

They map surpisingly well, as you'll probably see when I get around to putting
it on github

> I'm definitely interested in helping you implement those new models.
> Feel free to ping me on irc (masterzen on #puppet and #puppet-dev) or
> here if you need my help :) (and of course I'll be available live during
> puppet conf to answer questions)

That's great, I'll definitely get in touch with you there (username
gwmngilfen).
This week has descended into firefighting, but next week is looking good for
some more coding.

Nan, with regards to running "RUBYLIB=foo puppet master", how does that map
onto passenger? I assume I can put a SetEnv RUBYLIB /path/to/module in my
apache configuration? I'll certainly be trying that, but since I'm
writing this email
anyway, I thought I'd ask.

Thanks again for the support thus far :)
Greg

[Brice Figureau]

This looks like my own week :)

> Nan, with regards to running "RUBYLIB=foo puppet master", how does that map
> onto passenger? I assume I can put a SetEnv RUBYLIB /path/to/module in my
> apache configuration? I'll certainly be trying that, but since I'm
> writing this email
> anyway, I thought I'd ask.

You don't really need the provider code on the master. So you can just
use the agent/device to test. This one of course needs to access to your
custom code by using RUBYLIB, as in:

RUBYLIB=/path/to/module puppet device ...

--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!