This all sounds to me like there isn't much of an abstraction, since
there's no definition of what ought to happen (as opposed to what does
happen).
Surely, I want to be able to manage the xyz service in the same way no
matter what the operating system. If I take Felix' suggestion and
start hacking code, how do I know that it's consistent with behaviour
across all platforms?
My experience is that such questions are major barriers to enterprise
uptake of products as it's not clear whose responsibility it is to get
things working consistently across platforms or between product
releases.
To extend the cron example, it could be extended to 'a scheduler' with
a mapping to cron and, say, anacron, Windows' at system and autosys
(which is widely used in enterprises).
A dependency could be on a specific package, or on a generic
scheduler, which should reduce the replication in manifests.
In the particular instance of xinetd service on the learning vm, the
package is not installed (doh) and the directory /etc/xinetd.d is
actually owned by filesystem, rather than the xinetd package. There's
a whole ontology around these different entities that (imo) needs
clarification/definition if the use of puppet is to be consistent.
Tim
On Apr 21, 10:32 am, Thomas Bellman <bell...@nsc.liu.se> wrote:
> On 2011-04-21 10:19, Felix Frank wrote:
>
> > I don't think ralsh packs much intelligence in that regard, but relies
> > on the redhat provider instead.
>
> Yes, I was thinking "ralsh" as in "ralsh and all the subroutines from
> the rest of Puppet that it uses".
>
> > Peaking at the provider, it doesn't appear to do anything special. It
> > relies on the default (=init) method to find available services, which
> > is browsing /etc/init.d.
>
> > I concur that this can possibly be improved. If you do care for good
> > chkconfig integration (ralsh has nothing to do with it), you may want to
> > consider opening that bug after all ;-)
>
> Right, the 'resources' type of course also uses that functionality. I
> didn't think of that. As I said, it already works to do e.g.
>
> service { "rsync": enable => true; }
>
> to enable the xinetd-based rsync service, or
>
> ralsh service rsync
>
> to find out if it is enabled or not. At least in 0.25.5 and 2.6.6. The
> 'ensure' parameter that ralsh reports isn't in accordance with reality,
> though (it seems to be always returning "running")...
>
> /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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
