[prev in list] [next in list] [prev in thread] [next in thread] 

List:       puppet-dev
Subject:    [Puppet-dev] Puppet types for CIM/WBEM objects
From:       sseago () redhat ! com (Scott Seago)
Date:       2006-09-28 19:34:33
Message-ID: 1159472074.3376.90.camel () skagway
[Download RAW message or body]

On Thu, 2006-09-28 at 12:24 -0500, Luke Kanies wrote:
> Scott Seago wrote:
> > 
> > The code for this is currently checked into hg at
> > http://hg.et.redhat.com/hg/emd/libraries/puppet-conga-types
> 
> The README at this page seems to only talk about Conga stuff; I see no 
> mention of CIM, for instance.
> 
Ugh. Wrong URL -- sorry about that. Here's the right one:
http://hg.et.redhat.com/hg/emd/libraries/cim-puppet


> This is very cool.  I've often wanted to be able to reuse the work in 
> CIM but provide a simpler interface.
> 
> Do you have some examples of what CIM types are normally available? 
> Could we possibly autogenerate a bunch of Puppet types based on what CIM 
> types are available?  Do you see CIM as significantly expanding the 
> types of resources we could manage?
> 
The problem is there aren't really a lot of fully-functional completed
open source CIM providers out there. Most of what's currently available
is through the SBLIM project (http://sblim.sourceforge.net/), although
from what I've seen many of the SBLIM providers are read-only (what RPMs
are installed on this system, etc.) with the management bits missing. A
list of SBLIM providers is here:
http://sblim.sourceforge.net/instrumentation.html

There are two end-to-end SBLIM-based management apps -- one for DNS, and
one for SAMBA ( http://sblim.sourceforge.net/wbemsmt.html )  which,
theoretically, should provide fully-featured providers that could also
be managed by Puppet.

One of the reasons for CIM's lack of traction seems to be the difficulty
in writing providers. Another project we've worked on is attempting to
address this problem: Cimbiote (http://et.redhat.com/page/Cimbiote)
allows providers to be written in Python, and at the same time reduces a
lot of the repetitive boilerplate code which is required when writing
providers directly in C or C++.

My cim-puppet work is probably best thought about in the context of
Cimbiote. Although there aren't a bunch of existing providers which
cim-puppet suddenly opens up to puppet management, the thinking is that,
with tools to simplify provider generation, new providers that get
written can be (almost) trivially turned into puppet types.

As for autogenerating puppet types from CIM providers, I don't imagine
that it would be too difficult to do -- you can query the CIMOM for
class information (attributes, types, associations, etc.) which could
then be used to generate the type by calling newparam, newstate, etc. on
the results. David and I talked briefly about this possibility, but he
was of the opinion that explicit creation was better, so that you can
include appropriate type documentation and, as required, custom
validation. Also, we'd have to resolve the multi-object key issue before
going too far down this path. For example, the CIM_SoftwareElement class
(base class of the RPM CIM class), has a key consisting of Name,
Version, SoftwareElementState (i.e. Installable, Running, etc.),
SoftwareElementID, and TargetOperatingSystem.

Scott



[prev in list] [next in list] [prev in thread] [next in thread]