Puppet users - May 2010 - customizing an existing type & provider, or creating a new set

Good afternoon. I''ve just started playing with puppet, and I''m
currently stuck trying to figure out how to accomplish the following:

I want to add a property to the package type resource, so if one is on
a debian-based system they can specify from which "release" to install
a package and it''s dependencies. This is something I believe would
come in handy, especially to make it easier for admins to manage
packages coming from a combination of private/custom repos plus debian-
backports and/or testing repos.

So, for example, in one''s manifest would be the following:

package {
    "pupet":
      ensure  => latest,
      release => lenny-backports;
}

Which of course, is intended to keep puppet up-to-date using the
packages released under "lenny-backports" in the backports repo (which
of course would have already been set up in sources.list)

I really, really want to do this as a plugin, and not modify puppet''s
code directly, since that''s just taking the road to crazy-town when it
comes to system admin, which is why I''m learning puppet in the first
place!

I''ve attempted the following, all with no success:
  1. write a plugin that attempts to add the "release" property to
Puppet::Type.type(:package) (Puppet::Type::Package?)
  2. write a plugin that creates a type called "my_package" that
subclasses Puppet::Type.type(:package), and then a provider to use
that.
  3. Copy the package.rb and apt.rb source files into the plugin
directories and modify them with new names (my_package,my_apt)  and
add the new desired functionality...

So far, none of this has worked. I''m a total ruby newbie, but quite
experienced in other dynamic languages. However, trying to follow
what''s going on between type.rb and metatype/manager.rb et al
it''s
clear that I''m going to need a lot more knowledge of ruby''s
semantics
to do this via options 1 or 2... and I''m totally stumped as to why 3
does not work.

An example error message from running ''puppet --verbose --debug --
noop'' on a manifest that uses the new type...

  Parameter ensure failed: Validate method failed for class ensure:
undefined method `satisfies?'' for nil:NilClass

It''s clear there is way more magick happening here than meets the
untrained eye. (Not a criticism - I''m primarily a perl hacker :)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Have you considered just pinning this package via a file and requiring that
before this resource?

On May 23, 2010 3:31 PM, "Hercynium" <sscaffidi@gmail.com>
wrote:

Good afternoon. I''ve just started playing with puppet, and I''m
currently stuck trying to figure out how to accomplish the following:

I want to add a property to the package type resource, so if one is on
a debian-based system they can specify from which "release" to install
a package and it''s dependencies. This is something I believe would
come in handy, especially to make it easier for admins to manage
packages coming from a combination of private/custom repos plus debian-
backports and/or testing repos.

So, for example, in one''s manifest would be the following:

package {
   "pupet":
     ensure  => latest,
     release => lenny-backports;
}

Which of course, is intended to keep puppet up-to-date using the
packages released under "lenny-backports" in the backports repo (which
of course would have already been set up in sources.list)

I really, really want to do this as a plugin, and not modify puppet''s
code directly, since that''s just taking the road to crazy-town when it
comes to system admin, which is why I''m learning puppet in the first
place!

I''ve attempted the following, all with no success:
 1. write a plugin that attempts to add the "release" property to
Puppet::Type.type(:package) (Puppet::Type::Package?)
 2. write a plugin that creates a type called "my_package" that
subclasses Puppet::Type.type(:package), and then a provider to use
that.
 3. Copy the package.rb and apt.rb source files into the plugin
directories and modify them with new names (my_package,my_apt)  and
add the new desired functionality...

So far, none of this has worked. I''m a total ruby newbie, but quite
experienced in other dynamic languages. However, trying to follow
what''s going on between type.rb and metatype/manager.rb et al
it''s
clear that I''m going to need a lot more knowledge of ruby''s
semantics
to do this via options 1 or 2... and I''m totally stumped as to why 3
does not work.

An example error message from running ''puppet --verbose --debug --
noop'' on a manifest that uses the new type...

 Parameter ensure failed: Validate method failed for class ensure:
undefined method `satisfies?'' for nil:NilClass

It''s clear there is way more magick happening here than meets the
untrained eye. (Not a criticism - I''m primarily a perl hacker :)

--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 23, 8:14 pm, Nigel Kersten <nig...@google.com>
wrote:
> Have you considered just pinning this package via a file and requiring that
> before this resource?
I have, and already implemented that, thanks! :) However I can already
think of other situations where being able to extend existing types
would be desirable and make managing various things simpler and more
direct.

I plan on spending some time trying to write some simple types and
providers to hopefully learn a bit more about what''s going on and why
my initial approaches have all failed, but I would be greatly
appreciative of pointers and/or links to more documentation or
examples.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, May 24, 2010 at 1:09 PM, Hercynium <sscaffidi@gmail.com> wrote:
> On May 23, 8:14 pm, Nigel Kersten <nig...@google.com> wrote:
> > Have you considered just pinning this package via a file and requiring
> that
> > before this resource?
>
> I have, and already implemented that, thanks! :) However I can already
> think of other situations where being able to extend existing types
> would be desirable and make managing various things simpler and more
> direct.
>
> I plan on spending some time trying to write some simple types and
> providers to hopefully learn a bit more about what''s going on and
why
> my initial approaches have all failed, but I would be greatly
> appreciative of pointers and/or links to more documentation or
> examples.
>
I believe we actually have a feature request in for the apt provider to do
what you''ve asked for btw.


The approach you outlined in the initial mail looks like it should work at
first glance, can you post some more info about the actual errors you get
trying these different methods?


>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 24, 4:14 pm, Nigel Kersten <nig...@google.com>
wrote:
> I believe we actually have a feature request in for the apt provider to do
> what you''ve asked for btw.
>
Cool, I''ll look for it and subscribe. Even though the example I posted
is easily solved with pinning, there can be much more complicated
scenarios where tracking all the necessary pinned stuff could be
tedious, at best.
> The approach you outlined in the initial mail looks like it should work at
> first glance, can you post some more info about the actual errors you get
> trying these different methods?
Can do. What''s the preferable approach on this list? Posting to
pastebin/gist, or directly in-message?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 2010-05-24 22:32, Hercynium wrote:
> Can do. What''s the preferable approach on this list? Posting to
> pastebin/gist, or directly in-message?
Inline in the message, please.  Having to surf to a webpage to view
the information sucks, especially if you read mail offline.


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 25, 2010, at 2:47 AM, Thomas Bellman wrote:
> On 2010-05-24 22:32, Hercynium wrote:
> 
>> Can do. What''s the preferable approach on this list? Posting
to
>> pastebin/gist, or directly in-message?
> 
> Inline in the message, please.  Having to surf to a webpage to view
> the information sucks, especially if you read mail offline.
It''s also bad if someone''s looking in the archives and the
file''s gone.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.