On Fri, Jul 12, 2013 at 8:55 AM, Nan Liu <[email protected]> wrote: > On Fri, Jul 12, 2013 at 8:19 AM, Brice Figureau < > [email protected]> wrote: > >> On Fri, 2013-07-12 at 03:52 -0700, Markus Burger wrote: >> > We just released an internally developed puppet-networkdevice module >> > in the hope that some other folks might be interested in it :). >> > > Awesome! >
Absolutely! > > >> > It's currently still in an early stage but should be pretty usable for >> > the basic usecases. >> > >> > -> https://github.com/uniak/puppet-networkdevice >> > >> > I have one small request about the code. It doesn't make a huge difference right now, but putting the amount of code that you have in Puppet::Util increases the chance that there ends up being some sort of collision between your module and code in puppet itself. Instead of using Puppet::Util, I would suggest following the decision reached in https://projects.puppetlabs.com/issues/14149, which would mean that you should use PuppetX::Uniak::NetworkDevice. > > ## Overview >> > >> > The Cisco Networkdevice Module provides a common way to manage various >> > configuration properties with Puppet and was initially based on the >> > network_device utility provided by Puppet. >> >> Your development is much more complete than my very limited >> implementation, congrats! >> >> > Currently most providers, types, etc are suffixed with _ios as to >> > avoid collusion with the network_device code already provided by >> > puppet. >> >> That make sense, but you also apparently integrated some of the bits >> that were in the core (I was thinking about the transport classes). >> I won't speak for the core maintainers here, but that'd be great if you >> could have used what was in the core. >> >> What was preventing you to use the mechanisms/features that were already >> there? >> Is that you wanted to modify/add things on top of that? >> >> So now that we have this module, is it time to remove all the cisco >> stuff from the core, and leave only the base network device mechanism >> (possibly enriched by some of the functionalities this module provides)? > > > +1, it's always harder to iterate in puppet core, and much easier to > improve as a module for these type of functionality. I would much rather > update my module than upgrade puppet for these type of improvements. > > I agree. If this module covers all of the existing cases and more of the core modules, then I don't see why we shouldn't start deprecating the core ones and promote these. > Thanks, > > Nan > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13* **Register now and take advantage of the Early Bird discount - save 25%!* -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
