[racktables-users] Re: RESTful API for RackTables
- From: Les Mikesell <lesmikesell@xxxxxxxxx>
- To: racktables-users@xxxxxxxxxxxxx
- Date: Fri, 1 Jun 2012 12:29:18 -0500
On Fri, Jun 1, 2012 at 11:47 AM, Philip Durbin <philipdurbin@xxxxxxxxx> wrote:
>>
>> You must write an exporter/importer in some language, right?
Well, someone does for the data to be usable outside of the web page screen.
>> Why don't you choose the least painful option, and then be as
>> language-agnostic as you want while using the resulting export/import API?
I don't see an option that is not painful. Did I miss finding the well
documented, stable API?
> Alexey is correct. The "right" way to write a RESTful API for RackTables is
> write it in PHP using this guide:
>
> http://sourceforge.net/apps/mediawiki/racktables/index.php?title=RackTablesDevelGuide#API
Aside from not understanding PHP or how the dictionary works, I don't
see how you insert things or what the constraints are on the
relationships - or what order you'd have to create elements to make
them related. Perhaps most importantly, how can you retain a
relationship between something in the racktables DB with something
external that wants to update information about an existing device?
> I was mostly linking to
> http://blog.mattynick.com/blog/2012/05/31/getting-racktables-location-info-into-puppet/
> just to demonstrate a quick and dirty way to get data out of RackTables and
> into a language-agnostic format (YAML) with a Ruby script. Yes, it queries
> the database directly. Yes, the database schema could change. Yes, you're
> committing to maintaining your own code to provide this API for yourself.
Unless every function you'll ever need already exists and is
maintained by someone else in lockstep with the DB schema, I don't see
how you can avoid dealing with the underlying sql. And if you have to
do that, why not do it in a language you already know or the one which
already is handling the other end of the data you are importing or
exporting? Abstracting everything into REST with xml/json data would
be great, but if it isn't already there, someone is going to have to
deal with sql at some level.
> There's also this Racks/Bays Management Plugin for GLPI:
> http://plugins.glpi-project.org/spip.php?article8 . I've barely even looked
> at GLPI.
What I'd really like to see is a way to glue the fusioninventory
plugin that works with GLPI into racktables. It is sort of an
offshoot of the ocsinventory-ng agent that sends a hardware/software
inventory from each host in an xml format to a central server that
extracts it into its database. It can also remotely query VMware ESXi
hosts that can't run the agent to build a similar inventory. There
is also a way to poll snmp devices to include in the inventory but it
seems to use a different way to communicate that to GLPI instead of
the xml output. Unfortunately, OCS/GLPI/fusioninventory don't have a
good way to tie location/connection/power info to the device
inventory. And like Racktables, they seem to think nobody else should
be using the data in their database...
--
Les Mikesell
lesmikesell@xxxxxxxxx
Other related posts:
