Home

update 5/23/13

i have stalled on this project for awhile... mostly because i had a hard time reconciling a fully enumerated model of expression with one that can be statefully represented in restful GET urls (i.e. thousands of hosts don't fit in a url so well). my latest thinking is that wildcard/regex models work better with large inventories and GET urls and all the tooling that revolves around them (url sharing, bookmarks, command line curl, url shortening, etc). maybe someday i'll fiddle with enumerated tag exploration again, but for now let me know if you're interested in taking over where i've left things.

tostaa - Tag and hOST oriented Actions and Analytics

(warning - there are currently bugs and packaging issues with tostaa. i hope to solve them over time, but i decided to go ahead and publish prior to perfection :) if you're interested in implementing tostaa drop me a message in #tostaa at irc.freenode.net (i'm there at least a few hours each workday) or mail svdtostaa at jumpmark dot com)

tostaa is a query-by-example ui meant to explore an inventory of computing resources (hosts) with varied attributes (tags) and configurations (services). the main goal was to be able to discover, define, and take actions or make inquiries on nontrivial enumerations of these elements in an ad-hoc and iterative way. an approachable ajaxy interface, with expressive power over a tedious volume of fine grained controls and data. it has a plugin model for integrating with a general concept of target services. e.g. there is currently a nagios plugin (which falls into the action side of tostaa, e.g. muting/disabling bulk checks or scheduling bulk downtimes) and a ganglia plugin (which falls on the analytics side, overlaying metrics shared among hosts). the ui model is based on 3 dimensions of elements:

• host/resource name/identifier - tostaa was invented in the context of a data center environment with dedicated hosts. it's conceivable that it could be applied to a virtualized cloud environment, but i've yet to try. but the point is to organize a system as a collection of identified resources which are networked units of some amount of storage, cpu, and memory.

• tag - a very loosely structured and generalized way to organize the resources/hosts.

• service - these are host specific elements of the system on which to query or act.

services depend on the system tostaa is targeting. e.g. with the nagios plugin, services are the checks assigned to each host (beware of confusing terms here, nagios actually calls these checks services also, which is not coincidental since nagios was the first module i built). alternately, with the ganglia plugin, services are the metrics that are collected for each host.

tags are essential organizational spaces for hosts. they represent things like which rack or role or chassis type a host is. tags are more static than services in this sense... the services change within the ui depending on target system/module, tags do not. tags and services do not relate to eachother directly, however they both relate to hosts, and so relate to eachother indirectly. (not exactly a many-many map table but similar, and used in a similar way... there may be some standard data modeling term i'm missing here).

the tostaa theory is that these 3 dimensions are a useful and general way of expressing basic structures of commoditized systems of resources and their configurations. this expression is then useful as input to some sort of bulk operation or inquiry.

the tostaa ui

the ui has 3 panes - tags are on the left, hosts in the middle, and services on the right. widgets that parameterize an action or inquiry are along the top.

without clicking anything, you see some structure to the tags and services in the form of counts of hosts that match each tag/service.

once an element is clicked, the range of elements visible will narrow to the ones that map to the one(s) clicked. i.e. if you click a tag, all hosts which do not have that tag are hidden, or if you click a host, all tags which do not include that host are hidden. services behave just like tags do, and clicking them affects the visibility not only of hosts but also of each other. i.e. if a clicked tag hides all the hosts which match a service, that service will also be hidden. hosts play a relational role in this sort of language of clicking and narrowing, which is why they are in the middle pane of the ui. further clicks will further narrow the element ranges, un-clicking will widen the ranges, and doing this in an iterative process is what provides an exploratory experience.

once a final set of hosts and services has been selected/expressed (basically just a boolean inclusion or exclusion from the tag/service spaces), an action or inquiry is invoked on them. this action may be parameterized by a widget along the top. e.g. for nagios, the widget is a pulldown specifying something like scheduling downtime, and a textarea specifying the downtime comment.

the counts next to each visible tag/service are dynamic and indicate how many of the still-visible hosts would continue to appear if that tag/service were to be clicked... a sort of look-ahead metric that informs of the deeper structure of the inventory. these counts are actually very handy on their own merit for exploring the resources, and i often click around this ui without any intention of invoking an action or inquiry, just for the sake of answering quick questions like "how many 12 core hosts are in rack x" or "how many filesystems are monitored for hosts playing a mysql role".

4 minute screencast demo:
http://www.youtube.com/watch?v=XBvMh6zR1Ic