Puppet users - Sep 2008 - Pushing data into a CMDB (especially Remedy)

Hello Puppet users,

I was curious if anyone else works at an institution that uses Remedy,
particularly as a CMDB infrastructure.  We''re planning to do that and
so I''ve been tasked with writing integration tools so that Puppet can
feed data of interest up into that system.  If anyone is interested in helping
(whether you use Remedy or not), I''d be interested to build a team
around this effort.

Here is the breakdown:

The CMDB wants to know about systems and system facts.  This is easy with facter
and stored configs and stored facts.  We''ll just be writing a collector
to query these things out of the puppetmaster storage and feed that into the
CMDB.  The CMDB also wants to know about meta information like who the admin in
charge is, who the client is, what the purpose and description of the services
are.  These meta facts will be provided as either (a) meta resources created as
native types in puppet or (b) through an external node tool.

That''s the basic jist of it.  I''d love to hear from interested
parties or parties doing something similar.



-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
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, Sep 22, 2008 at 12:25 PM, Digant C Kasundra <digant@stanford.edu>
wrote:
>
> Hello Puppet users,
>
> I was curious if anyone else works at an institution that uses Remedy,
particularly as a CMDB infrastructure.  We''re planning to do that and
so I''ve been tasked with writing integration tools so that Puppet can
feed data of interest up into that system.  If anyone is interested in helping
(whether you use Remedy or not), I''d be interested to build a team
around this effort.
>
That''s interesting. I had only ever seen Remedy used as a ticket
tracking system.

Or am I thinking about a different Remedy? Is this to meet an ITIL
standard? If it is the same Remedy, what additional modules would be
used for this.  I had been looking at the CMDB part as something that
would need to wrap around puppet and say an asset tracking system.
> Here is the breakdown:
>
> The CMDB wants to know about systems and system facts.  This is easy with
facter and stored configs and stored facts.  We''ll just be writing a
collector to query these things out of the puppetmaster storage and feed that
into the CMDB.  The CMDB also wants to know about meta information like who the
admin in charge is, who the client is, what the purpose and description of the
services are.  These meta facts will be provided as either (a) meta resources
created as native types in puppet or (b) through an external node tool.
>
> That''s the basic jist of it.  I''d love to hear from
interested parties or parties doing something similar.
>
>
>
> --
> Digant C Kasundra <digant@stanford.edu>
> Technical Lead, ITS Unix Systems and Applications, Stanford University
>
> >
>


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi,

I''m interested, I''ve already done some basic work on the
puppet side.
In our setup we decided not to use storeconfig (due to technical limitations
of having too many puppet masters in different locations), therefor, we have
re implemented many of facts importing and collecting.

I would assume it should not be a big deal to push the data forward to
remedy CMDB.

Cheers,
Ohad

On Tue, Sep 23, 2008 at 2:25 AM, Digant C Kasundra
<digant@stanford.edu>wrote:
>
> Hello Puppet users,
>
> I was curious if anyone else works at an institution that uses Remedy,
> particularly as a CMDB infrastructure.  We''re planning to do that
and so
> I''ve been tasked with writing integration tools so that Puppet can
feed data
> of interest up into that system.  If anyone is interested in helping
> (whether you use Remedy or not), I''d be interested to build a team
around
> this effort.
>
> Here is the breakdown:
>
> The CMDB wants to know about systems and system facts.  This is easy with
> facter and stored configs and stored facts.  We''ll just be writing
a
> collector to query these things out of the puppetmaster storage and feed
> that into the CMDB.  The CMDB also wants to know about meta information
like
> who the admin in charge is, who the client is, what the purpose and
> description of the services are.  These meta facts will be provided as
> either (a) meta resources created as native types in puppet or (b) through
> an external node tool.
>
> That''s the basic jist of it.  I''d love to hear from
interested parties or
> parties doing something similar.
>
>
>
> --
> Digant C Kasundra <digant@stanford.edu>
> Technical Lead, ITS Unix Systems and Applications, Stanford University
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Yes, I would be interested in this as well.  We posited that Puppet
and facter could make a nice foundation for a CMDB, but you need more
data.  It wouldn''t be as feature complete as, say BMC''s Atrium
product, but in most cases you don''t need that... But what you do need
is the information kept up to date.  We use Remedy today to log rack,
row, shelf in our DC''s for when resources are installed... BUt we have
found that it is RAPIDLY out of date as things move, new racks are
added, etc.

While I don''t agree with all of it as being necessary check out the
ITIL v3 CMDB definition for a pretty complete definition.

On Sep 22, 11:35 pm, "Ohad Levy" <ohadl...@gmail.com>
wrote:
> Hi,
>
> I''m interested, I''ve already done some basic work on the
puppet side.
> In our setup we decided not to use storeconfig (due to technical
limitations
> of having too many puppet masters in different locations), therefor, we
have
> re implemented many of facts importing and collecting.
>
> I would assume it should not be a big deal to push the data forward to
> remedy CMDB.
>
> Cheers,
> Ohad
>
> On Tue, Sep 23, 2008 at 2:25 AM, Digant C Kasundra
<dig...@stanford.edu>wrote:
>
>
>
> > Hello Puppet users,
>
> > I was curious if anyone else works at an institution that uses Remedy,
> > particularly as a CMDB infrastructure.  We''re planning to do
that and so
> > I''ve been tasked with writing integration tools so that
Puppet can feed data
> > of interest up into that system.  If anyone is interested in helping
> > (whether you use Remedy or not), I''d be interested to build a
team around
> > this effort.
>
> > Here is the breakdown:
>
> > The CMDB wants to know about systems and system facts.  This is easy
with
> > facter and stored configs and stored facts.  We''ll just be
writing a
> > collector to query these things out of the puppetmaster storage and
feed
> > that into the CMDB.  The CMDB also wants to know about meta
information like
> > who the admin in charge is, who the client is, what the purpose and
> > description of the services are.  These meta facts will be provided as
> > either (a) meta resources created as native types in puppet or (b)
through
> > an external node tool.
>
> > That''s the basic jist of it.  I''d love to hear from
interested parties or
> > parties doing something similar.
>
> > --
> > Digant C Kasundra <dig...@stanford.edu>
> > Technical Lead, ITS Unix Systems and Applications, Stanford University
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> > I was curious if anyone else works at an institution that uses
> Remedy, particularly as a CMDB infrastructure.  We''re planning to
do
> that and so I''ve been tasked with writing integration tools so
that
> Puppet can feed data of interest up into that system.  If anyone is
> interested in helping (whether you use Remedy or not), I''d be
> interested to build a team around this effort.
> >
> 
> That''s interesting. I had only ever seen Remedy used as a ticket
> tracking system.
> 
> Or am I thinking about a different Remedy? Is this to meet an ITIL
> standard? If it is the same Remedy, what additional modules would be
> used for this.  I had been looking at the CMDB part as something that
> would need to wrap around puppet and say an asset tracking system.
> 
I thought I replied to this but I can''t seem to find the reply in my
inbox so I''ll reply again just in case.
Yes, this is Remedy the ticket tracking system, but it has modules/components
for CMDB so that you can tie tickets to "the world view" or some such
and do root cause analysis (supposedly) and run nifty reports on which servers
had which kind of issues and trouble tickets, blah blah blah.  Things I
don''t necessarily care about but I do know that I''m expected
to feed data into it and I don''t want to duplicate data I already have
based on facter and puppet.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

----- "Ohad Levy" <ohadlevy@gmail.com> wrote:
> Hi,
> 
> I''m interested, I''ve already done some basic work on the
puppet side.
> In our setup we decided not to use storeconfig (due to technical
> limitations of having too many puppet masters in different locations),
> therefor, we have re implemented many of facts importing and
> collecting.
> 
> I would assume it should not be a big deal to push the data forward to
> remedy CMDB.
> 
> Cheers,
> Ohad
Can you talk a little more about what this is.  How are you importing and
collecting these facts.  I''d love to try out this solution here and see
how it performs.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

----- "Jeff Leggett" <jeffrey.leggett@etrade.com> wrote:
> Yes, I would be interested in this as well.  We posited that Puppet
> and facter could make a nice foundation for a CMDB, but you need more
> data.  It wouldn''t be as feature complete as, say BMC''s
Atrium
> product, but in most cases you don''t need that... But what you do
> need
> is the information kept up to date.  We use Remedy today to log rack,
> row, shelf in our DC''s for when resources are installed... BUt we
> have
> found that it is RAPIDLY out of date as things move, new racks are
> added, etc.
> 
> While I don''t agree with all of it as being necessary check out
the
> ITIL v3 CMDB definition for a pretty complete definition.
I agree and what I''m looking at is a practical meeting of what I need
to know about my systems and indeed what I do know about my systems and what the
upper pay grades want (i.e. an ITIL CMDB).  I''ll likely end up drafting
a proposal of the solution and what it might look like and work on the
interconnects in an open source, collaborative fashion.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---