Am Freitag, 12. Juli 2013 22:03:02 UTC+2 schrieb Andy Parker: > > On Fri, Jul 12, 2013 at 11:36 AM, Brice Figureau < > brice-...@daysofwonder.com <javascript:>> wrote: > >> On 12/07/13 18:04, Andy Parker wrote: >> > On Fri, Jul 12, 2013 at 8:55 AM, Nan Liu <nan...@gmail.com<javascript:> >> > <mailto:nan...@gmail.com <javascript:>>> wrote: >> > >> > On Fri, Jul 12, 2013 at 8:19 AM, Brice Figureau >> > <brice-...@daysofwonder.com <javascript:> >> > <mailto:brice-...@daysofwonder.com <javascript:>>> 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. >> > Thanks for the hint!
> >> And also integrate back the modifications to the fundations into core. >> >> > I didn't notice any modifications. There are some monkey patches (scares > me a little...they are everywhere, but not really "good"). What are the > modifications you are talking about? > The transport classes that are in the core lacked some very small features like noop support and a very simple cache thats pretty useful for the way we implanted the model properties. All in all this should be a pretty small pull request. The Module is still in an very early stage and currently in a dire need of some refactoring / cleanup, there is a lot of copy&paste code floating around in the models (i think your referring to this ?). We hope to clean everything up next Week. > > >> > > ## 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. >> >> Sure, but this module also contains duplication with some of the feature >> that are in core. I'd hate to remove all the network device stuff for >> core (but that's your call obviously). I'd prefer to integrate what >> required Markus to duplicate, instead of removing everything from the >> core. >> >> Does it make sense? >> > > I'd really like to slim down the core and work toward things like this > living outside. Then we can make the decisions about bringing it all back > together for packaging. As Nan said, keeping it out of core allows it to > iterate faster. > > I'm not proposing removing the network devices feature (unless something > better comes along), but support for specific devices should probably live > outside. > > >> -- >> Brice Figureau >> My Blog: http://www.masterzen.fr/ >> >> -- >> 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+...@googlegroups.com <javascript:>. >> To post to this group, send email to puppe...@googlegroups.com<javascript:> >> . >> 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 <javascript:> > 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.
