[colug-432] CMDB, was Re: virtualization, clouds, and infrastructure

[Scott McCarty]

I suspected as much, but what I want is an open source CMDB that has an API
(REST would be nice). The closest thing is, I think, like you guys say, a
homegrown solution. The only magic for me of an open source project would be
bundling best practices of what information to gather/have on hand (a SQL
schema file might might be good enough to spread to other home grown
solutions) and a web based API, such as REST.

Scott M

On Fri, Dec 17, 2010 at 9:01 AM, Richard Troth <rmt at casita.net> wrote:

> > The only successful CMDB's I've seen had these qualities:
> > 1) home grown
> > 2) built on traditional DBs (mostly relational)
> > 3) tightly integrated to the mechanism that actually makes the change
> > 4) weren't called a CMDB
>
>
> Amen!
>
> I have worked for software companies as well as "customer shops".  One
> employer put substantial people and resources into their CMDB product.
>  I thought then that it was a grand mistake.
>
> Jonathan's right.  CMDB has to be home-grown because it has to fit in
> with >your< plans and policies for handling the systems (the mechanism
> that actually makes the change).  Even flat files are better than
> vendor CMDB if they're home grown.
>
> -- R;   <><
>
>
>
>
>
>
> On Fri, Dec 17, 2010 at 01:15, Jonathan Hogue <jon at hogue.org> wrote:
> >> On the devops toolchain mailing list CMDBs came up a while back and if I
> >> remember right, it is pretty hard to find a good standalone solution
> that
> >> has an API and is open source. What are you using?
> >
> > I was on a project team at Nationwide that tried to implement 2
> > different enterprise CMDBs. Neither one really worked. Also, I worked
> > with configuration management on amazon's ordering software.
> >
> > The only successful CMDB's I've seen had these qualities:
> > 1) home grown
> > 2) built on traditional DBs (mostly relational)
> > 3) tightly integrated to the mechanism that actually makes the change
> > 4) weren't called a CMDB
> >
> > The most successful one I've seen required all changes (server,
> > network, code build, deployment) to be specifically requested through
> > a home grown web tool, and the completion of the request updated the
> > configuration. (Often, the changes were implemented automatically,
> > once approved).
> >
> > I know... Holy Grail, but completely obtainable (but it can't be
> > purchased off the shelf.)
> > _______________________________________________
> > colug-432 mailing list
> > colug-432 at colug.net
> > http://lists.colug.net/mailman/listinfo/colug-432
> >
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20101217/4455a2c2/attachment.html