From: John Bollinger John Bollinger Reply: [email protected] [email protected] Date: February 3, 2014 at 4:04:57 PM To: [email protected] [email protected] Subject: Re: [Puppet-dev] Puppet Custom Types, the easy way
On Saturday, February 1, 2014 7:48:53 AM UTC-6, bert hajee wrote: The discussion seems to go in the direction of not having a provider. I must have missed all that. Yeah, I think that would be a bad overall direction, both because it reduces flexibility, and also because over time Puppet will switch to requiring providers. easy_type is by no means at all meant to stop using a provider. Actually, it is by no means a total replacement for the Type and Provider pattern. What it is, is an add-on module for people, less knowledgeable about Puppet (and the intricacies of Types and providers) to have a custom type for an easy kind of resource. And as far as it goes, it looks like a good and useful tool, as long as its limits are understood. Probably only on one kind of OS. I think that's an understatement. Inasmuch as the key methods are defined on the type, the module really supports only custom types with a single provider. That is to say, although additional providers could be written, it looks like easy_type would start to get in the way more than it helps for the second and subsequent provider. That's not necessarily a problem in any particular case, but it does make easy_type a special-purpose tool. That said about the current discussion, what I like about the discussion, is that we seem to all have the idea, it should be easier to make custom types. While we disagree on (at least some) of the directions I took with easy_type. Why not turn this into a discussion on what we would like to see in an easy way to build a type. I'l start, but please join: - A way to keep it close to people who know about the resource, but less about Puppet - Be able to easy abstract different OS-es and version (Like the current provider - Make it easier to call a set of standard available (and extendable) validators - Make it easier to call a set of standard available (and extendable) mungers. - Make it easy to gradually build the os command by stating a base part and extending it if a property or a name is specified in the resource definition. Absolute top of my list, ever since I first played with custom types: - Formal, complete, public documentation of the API Puppet provides to custom types and providers - Formal, complete, public documentation of the API Puppet expects custom types and providers to expose Nothing else even comes close. The guides PL provides around this area are helpful -- and more so now than they used to be -- but they are not an adequate substitute for bona fide API docs. Moreover, without good reference docs it's hard even to discuss what new features could benefit Puppet, because there is no shared understanding of what Puppet already has. Hopefully EricS can chime in here, but I know API docs are something the team is working on pretty heavily. The main problem in this area is that there’s quite a bit of stuff that also needs to be deprecated, so the balance is between fixing things vs documenting them. -- http://puppetlabs.com | http://about.me/lak | @puppetmasterd -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/etPan.52f08398.6353cd2.20af%40surfer-172-29-1-197-hotspot.s-bit.nl. For more options, visit https://groups.google.com/groups/opt_out.
