Grains based CMDB?

[Tony Hays]

Curious if anyone has thought about doing a ground up CMDB based on data from grains.  Was trolling around Ansible-land and saw Ansible CMDB and figured someone has probably implemented the same kind of thing on this side of the track.

[Colton Myers]

We at Adobe have a home-grown CMDB which we have integrated with Salt. We can audit grains information on the minion against what is stored in our CMDB about the same system.

In my opinion the value of a CMDB is as a centralized source of truth for your infrastructure. Trying to use the grains system seems problematic because grains information is dependent on being generated on the minions.

You could potentially do something with pillar, since that is centrally-located. In any case, if you settle on a CMDB system, chances are you'll be able to interface with it using an external_pillar module or custom grain module.

Hopefully my rambling is in some way helpful.

--

Colton Myers

@basepi

On Tue, May 31, 2016 at 4:06 PM, Tony Hays <t0ny...@gmail.com> wrote:

Curious if anyone has thought about doing a ground up CMDB based on data from grains.  Was trolling around Ansible-land and saw Ansible CMDB and figured someone has probably implemented the same kind of thing on this side of the track.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shane Gibson]

Tony,

You might take a look at the Range++ project that friend and former colleague of mine wrote.  It's a re-implementation of the Yahoo libCrange solution.  

  https://github.com/jbeverly/rangexx 

Essentially, it's designed to be a Configuration Management Service (I *hate* the term "CMDB" ... :-) ), which has Salt supported targeting capabilities via the 'salt --range ....' syntax (or the Compound Matcher of 'R@' syntax).  It allows you to define your infrastructure, and define your relationships between environment, hardware, operating systems, software, and services - and then utilize that data natively within Salt as your configuration management data source of truth. 

As Colton states - the value of a good centralized source of truth (eg CMS) can't be under estimated.  

Note that the Range++ solutions does not have a fancy web front end, and it does require a bit of work to initially set up and to describe your environment and populate the data.  It's definitely not the easiest to set up.  But in the end, the native Salt integration might make it worth the effort for you. 

~~shane 

[Jeremy McMillan]

I'm not certain this discussion has enough context around what we mean by CMDB to really help each other, especially with the assumption SaltStack is already operating and the CMDB would be added on.

[matthew...@device42.com]

Hey Tony,

If you're still looking, you might want to check out Device42. It wasn't built ground up around Salt, per-se, however Device42's CMDB is quite capable. Relevance being that an Open Source integration that can pull data from Salt Grains and sync it to Device42's CMDB was released somewhat recently. 

This is the Device42 page on it: http://www.device42.com/integrations/saltstack/ 

...and this is the integration [on github]: https://github.com/device42/salt_to_device42_sync

It may be worth a look. As the Adobe poster below said -- the real value of the CMDB is as a central source of record (truth) about your infrastructure, so taking it a step further, you can do things like visualize & verify your deployment, etc. with Device42.

Hope this is helpful, and don't hesistate to reach out if there's anything at all I can assist with.

Matt

[Matthew Altieri]

If you're still looking, you might want to check out Device42. It wasn't built ground up around Salt, per-se, however Device42's CMDB is quite capable. Relevance being that an Open Source integration that can pull data from Salt Grains and sync it to Device42's CMDB was released somewhat recently. 

This is the Device42 page on it: http://www.device42.com/integrations/saltstack/ 

...and this is the integration [on github]: https://github.com/device42/salt_to_device42_sync

It may be worth a look. As the Adobe poster below said -- the real value of the CMDB is as a central source of record (truth) about your infrastructure, so taking it a step further, you can do things like visualize & verify your deployment, etc. with Device42.

Hope this is helpful, and don't hesistate to reach out if there's anything at all I can assist with.

Matt

Matt Altieri

Device42, Inc.

West Haven CT 06516

http://www.device42.com

--

> Curious if anyone has thought about doing a ground up CMDB based on data
> from grains. Was trolling around Ansible-land and saw Ansible CMDB

> <https://github.com/fboender/ansible-cmdb> and figured someone has probably