Am Freitag, 12. Juli 2013 22:03:02 UTC+2 schrieb Andy Parker:
>
> On Fri, Jul 12, 2013 at 11:36 AM, Brice Figureau <
> [email protected] <javascript:>> wrote:
>
>> On 12/07/13 18:04, Andy Parker wrote:
>> > On Fri, Jul 12, 2013 at 8:55 AM, Nan Liu <[email protected]<javascript:>
>> > <mailto:[email protected] <javascript:>>> wrote:
>> >
>> >     On Fri, Jul 12, 2013 at 8:19 AM, Brice Figureau
>> >     <[email protected] <javascript:>
>> >     <mailto:[email protected] <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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<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
> [email protected] <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 [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.


Reply via email to