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.<div>
<br></div><div>Scott M<br><br><div class="gmail_quote">On Fri, Dec 17, 2010 at 9:01 AM, Richard Troth <span dir="ltr"><<a href="mailto:rmt@casita.net">rmt@casita.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> The only successful CMDB's I've seen had these qualities:<br>
> 1) home grown<br>
> 2) built on traditional DBs (mostly relational)<br>
> 3) tightly integrated to the mechanism that actually makes the change<br>
> 4) weren't called a CMDB<br>
<br>
<br>
</div>Amen!<br>
<br>
I have worked for software companies as well as "customer shops". One<br>
employer put substantial people and resources into their CMDB product.<br>
I thought then that it was a grand mistake.<br>
<br>
Jonathan's right. CMDB has to be home-grown because it has to fit in<br>
with >your< plans and policies for handling the systems (the mechanism<br>
that actually makes the change). Even flat files are better than<br>
vendor CMDB if they're home grown.<br>
<font color="#888888"><br>
-- R; <><<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
On Fri, Dec 17, 2010 at 01:15, Jonathan Hogue <<a href="mailto:jon@hogue.org">jon@hogue.org</a>> wrote:<br>
>> On the devops toolchain mailing list CMDBs came up a while back and if I<br>
>> remember right, it is pretty hard to find a good standalone solution that<br>
>> has an API and is open source. What are you using?<br>
><br>
> I was on a project team at Nationwide that tried to implement 2<br>
> different enterprise CMDBs. Neither one really worked. Also, I worked<br>
> with configuration management on amazon's ordering software.<br>
><br>
> The only successful CMDB's I've seen had these qualities:<br>
> 1) home grown<br>
> 2) built on traditional DBs (mostly relational)<br>
> 3) tightly integrated to the mechanism that actually makes the change<br>
> 4) weren't called a CMDB<br>
><br>
> The most successful one I've seen required all changes (server,<br>
> network, code build, deployment) to be specifically requested through<br>
> a home grown web tool, and the completion of the request updated the<br>
> configuration. (Often, the changes were implemented automatically,<br>
> once approved).<br>
><br>
> I know... Holy Grail, but completely obtainable (but it can't be<br>
> purchased off the shelf.)<br>
> _______________________________________________<br>
> colug-432 mailing list<br>
> <a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
> <a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
><br>
<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</div></div></blockquote></div><br></div>