Inventory db integration


#1

We use collins [1] as an asset database. It keeps tracks of racks,
switches, servers etc., the state of those things (new, unallocated,
broken), and basically does a lot of cool api & callback driven stuff to
get us from servers on a pallet to running chef-client.

Collins keeps tracks of an arbitrary set of tags about each asset in
addition to inferred hardware and network information. We would like to
be able to expose those tags to chef as attributes. As a trivial
example: if collins says a server is in “maintenance mode” we would like
to have chef edit /etc/motd to say something to that effect.

We have explored two options so far with some help from folks in #chef:

  • Just call out to the collins api using the collins-client ruby
    library inside select cookbooks
  • Write an ohai plugin that dumps everything from collins into ohai.

The first one seemed easy to write but doesn’t feel awesome. (Call this
function to get a value instead of values magically appearing.) The
ohai plugin route would (I think) get the magic “attributes just show
up” workflow. But it didn’t seem right to duplicate all the data from
one system-of-record into another.

Is there a third option? Are there other examples of injecting HWDB data
into chef?

[1] http://tumblr.github.io/collins/index.html


#2

We’re mostly doing the former with relation to our CMDB (insofar as
individual cookbooks make particular associations between applications and
servers), but I think a blend of both approaches is necessary - read data
out of Ohai, but have your cookbooks make assertions using a client-based
LWRP. That way, you always know where you stand, i.e.:

include_recipe “cmdb::default”

cmdb_associate_node_with_application “some_application” do
(resource-specific attributes)
not_if node[:cmdb][:applications].has_key?(:some_application)
end

On Tue, Apr 16, 2013 at 5:18 AM, Chris Burroughs
chris.burroughs@gmail.comwrote:

We use collins [1] as an asset database. It keeps tracks of racks,
switches, servers etc., the state of those things (new, unallocated,
broken), and basically does a lot of cool api & callback driven stuff to
get us from servers on a pallet to running chef-client.

Collins keeps tracks of an arbitrary set of tags about each asset in
addition to inferred hardware and network information. We would like to
be able to expose those tags to chef as attributes. As a trivial
example: if collins says a server is in “maintenance mode” we would like
to have chef edit /etc/motd to say something to that effect.

We have explored two options so far with some help from folks in #chef:

  • Just call out to the collins api using the collins-client ruby
    library inside select cookbooks
  • Write an ohai plugin that dumps everything from collins into ohai.

The first one seemed easy to write but doesn’t feel awesome. (Call this
function to get a value instead of values magically appearing.) The
ohai plugin route would (I think) get the magic “attributes just show
up” workflow. But it didn’t seem right to duplicate all the data from
one system-of-record into another.

Is there a third option? Are there other examples of injecting HWDB data
into chef?

[1] http://tumblr.github.io/collins/index.html


#3

I’m still trying to work this out as well, but I’ve been leaning towards
handling it largely on a datapoint by datapoint basis, where the deciding
criteria for any given datapoint is “whatever tool can provide the answer
most accurately”. Usually that means any tool where the data is manually
populated is least desirable, but sometimes that’s all you’ve got.

System type, manufacturer, product_name -> ohai (ipmi)
Upstream switch connections -> cron job, pcap against CDP, ohai plugin
(hack, but way better than manual)
Datacenter rack and U -> query asset management system because I have no
other choice

On Tue, Apr 16, 2013 at 1:34 PM, steve . leftathome@gmail.com wrote:

We’re mostly doing the former with relation to our CMDB (insofar as
individual cookbooks make particular associations between applications and
servers), but I think a blend of both approaches is necessary - read data
out of Ohai, but have your cookbooks make assertions using a client-based
LWRP. That way, you always know where you stand, i.e.:

include_recipe “cmdb::default”

cmdb_associate_node_with_application “some_application” do
(resource-specific attributes)
not_if node[:cmdb][:applications].has_key?(:some_application)
end

On Tue, Apr 16, 2013 at 5:18 AM, Chris Burroughs <
chris.burroughs@gmail.com> wrote:

We use collins [1] as an asset database. It keeps tracks of racks,
switches, servers etc., the state of those things (new, unallocated,
broken), and basically does a lot of cool api & callback driven stuff to
get us from servers on a pallet to running chef-client.

Collins keeps tracks of an arbitrary set of tags about each asset in
addition to inferred hardware and network information. We would like to
be able to expose those tags to chef as attributes. As a trivial
example: if collins says a server is in “maintenance mode” we would like
to have chef edit /etc/motd to say something to that effect.

We have explored two options so far with some help from folks in #chef:

  • Just call out to the collins api using the collins-client ruby
    library inside select cookbooks
  • Write an ohai plugin that dumps everything from collins into ohai.

The first one seemed easy to write but doesn’t feel awesome. (Call this
function to get a value instead of values magically appearing.) The
ohai plugin route would (I think) get the magic “attributes just show
up” workflow. But it didn’t seem right to duplicate all the data from
one system-of-record into another.

Is there a third option? Are there other examples of injecting HWDB data
into chef?

[1] http://tumblr.github.io/collins/index.html