On Fri, Jul 12, 2013 at 8:55 AM, Nan Liu <nan....@gmail.com> wrote: > On Fri, Jul 12, 2013 at 8:19 AM, Brice Figureau < > brice-pup...@daysofwonder.com> 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 puppet-dev+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Andrew Parker a...@puppetlabs.com 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 puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
