[racktables-users] Re: Ansible
- From: Denis Ovsienko <denis@xxxxxxxxxxxxx>
- To: "racktables-users" <racktables-users@xxxxxxxxxxxxx>
- Date: Thu, 04 Oct 2018 12:05:23 +0100
---- On Wed, 03 Oct 2018 15:33:11 +0100 David Flamini <flaminidavid@xxxxxxxxx>
wrote ----
Hi Sander,
This may no be exactly what you are looking for but it will point you in the
right direction, you will need to join on a couple more tables to get the
complete info on a particular object.I recommend MySQL Workbench to try out
the queries first.
btw if you are using Ansible Tower I have some examples on how to build the
inventory from custom script.
#!/usr/bin/env python
#Require: mysql-python Depends on: libmysqlclient-dev
import MySQLdb
db = MySQLdb.connect(host=racktables_db_host,
user=racktables_db_user,
passwd=racktables_db_passwd,
db=racktables_db_name)
cur = db.cursor()
# Get Node Names from Racktables (by Tag)
cur.execute('''SELECT Object.name FROM TagStorage
INNER JOIN Object ON TagStorage.entity_id=Object.id
INNER JOIN TagTree ON TagStorage.tag_id=TagTree.id
WHERE TagTree.tag="TAG_NAME_HERE"
''')
for node_row in cur.fetchall():
node_name = node_row[0] # Do something here, i.e.
start building your Ansible inventory
Hello all.
Looks like this could work for a single tag. But I would not (and do not)
retrieve a list of objects with the tag through SQL in my code because I would
like to avoid the dependency on schema changes, and to take the advantage of
RackCode like this:
--------------------------------------------------------------------------------------
<?php
$script_mode = TRUE;
require_once '/usr/local/racktables/wwwroot/inc/init.php';
$filter = '({VM} or {server}) and ({FreeBSD} or {Linux}) and not {disable
monitoring}';
foreach (scanRealmByText ('object', $filter) as $object)
# do something with the object
--------------------------------------------------------------------------------------
Obviously, not everything is possible from within PHP and on the same host
where RackTabels is installed, so a typical scenario works like this:
centralized system X: RackTables, give me the list of hostnames for this job
RackTables: server1, server2, server3, server4, ...
(X spends a long time doing some work)
X: RackTables, for server2 and server3 the updated details/status are as
follows: ...
(or like this)
server1: RackTables, here is my serial number and IP addresses, what is the
list of services I should deploy and run?
server2: (idem)
server3: (idem)
RackTables: (immediately provides an individual response to each)
server1, later: RackTables, my latest status is success
server2, later: RackTables, my latest status is error
server3: (does not report, so looks different and can be investigated in due
time)
(or like this)
RackTables: server1, run a local Perl script right now and give me the stderr
and stdout immediately
RackTables: server2, run a local Python script... (idem)
RackTables: server3, run a local PHP script... (idem)
RackTables: server4 (connection times out)
This or another way, exchanging the data across different software and/or
different hosts requires some planning and some intermediate representation. I
have seen plain text, CSV, XML and JSON serving this purpose (specific choice
depends on the data structure and on the encoding/decoding capabilities at each
end of the interface).
There are also factors of scalability, security and robustness to consider:
* which hosts try connect to which hosts
* who pushes/pulls raw data
* who processes the data, derives other data, applies heuristics and makes
decisions
* what happens when the data exchange takes a long time to complete/fail and
there is a lot of exchanges to attempt every X minutes/seconds
* which hosts are allowed to make which exchanges and under what conditions
Over time I have implemented quite a few such interfaces to RackTables. Some of
them were as simple as a single SQL SELECT, so the need for an API or a
messaging convention was not quite striking. On the other hand, there were
cases that required complexity a couple levels above that of plain SQL. Those
assorted interfaces tend to accumulate over time, and it really helps to keep
them under one hood so they can be individually evolved when required (ideally
in a way not visible to the other end of the API).
So I would say once again SQL is an acceptable last resort interface to
RackTables, but not a good first choice for cases where better means are
available.
--
Denis Ovsienko
Other related posts:
