Intriguingly, on a fedora 13 host, using puppet-0.25.5-1.fc13.noarch,
information about xinetd *is* returned by
puppet resource service.
the version on the learning machine is:
pe-puppet-2.6.4-7.el5
Is the change in behaviour a bug? how can I tell?
On Apr 20, 6:42 pm, Tim Coote <tim.coo...@googlemail.com> wrote:
> Hi Ben
> [I'm using the training machine from puppetlabs]
> puppet resource service xinetd
>
> returns info about xinetd.
>
> But
> puppet resource service
> does not include anything about xinetd, which sounds like a bug to me.
>
> I understand the limitations of what can be recovered, but that's an
> implementation constraint. The documentation talks about an
> Abstraction Layer. From a design perspective, I'd expect such an
> interface to explicitly tell me what it cannot recover, rather than
> silently not returning it, as I've no way of knowing that there's a
> constraint on the o/s / distro vs a bug in puppet.
>
> Tim
> On Apr 20, 2:17 am, Ben Hughes <b...@puppetlabs.com> wrote:
>
>
>
>
>
>
>
> > On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
> > > Is there a canonical definition of the service type abstraction, or is
> > > the definition just how the implementation behaves?
>
> > What happens when you do:
>
> > $ puppet resource service xinetd
>
> > That should hopefully give you the output for that.
>
> > Resource isn't, say, a system profiling tool. It's more an interface to
> > resources you have. And while some will give you all the information you
> > may want ('user' for example), not all of them can.
>
> > --
> > Ben Hughes ||http://www.puppetlabs.com/
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
