Jump to: navigation, search


OpenStack Configuration Discovery

The charter for the project is focused narrowly on discovering pre-existing infrastructure and installed or running software. For example, given a URL and some credentials, discover which server(s) the URL is hosted on, the topology of the infrastructure and what software is running on each server, as well as, pertinent settings for commonly encountered software like apache, varnish, and mysql.

Quick overview

Use Cases

We expect that the output of a configuration discovery tool could be used for:

  • Troubleshooting unfamiliar environments
  • Configuration analysis (compare the discovered state vs a library of best practices)
  • System State Verification
  • Detecting configuration changes over time
  • Heat Template generation
  • Solum Application creation/import
  • Creation of Chef recipes/cookbooks, Puppet modules, Ansible playbooks, setup scripts, etc.

Getting Started

The project will begin with a simple command-line tool so that new users can discover a configuration without needing to setup additional infrastructure. A mockup for the output is listed below:

$ satori www.foo.com
   www.foo.com resolves to IPv4 address
Domain: foo.com
   Registered at TUCOWS DOMAINS INC.
   Expires in 475 days.
   Name servers:
Host: (www.foo.com) is hosted on a Nova Instance
   Instance Information:
       URI: https://nova.api.somecloud.com/v2/111222/servers/d9119040-f767-414
       Name: sampleserver01.foo.com
       ID: d9119040-f767-4141-95a4-d4dbf452363a
   System Information:
       Ubuntu 12.04 installed
       Server was rebooted 11 days, 22 hours ago
       /dev/xvda1 is using 9% of its inodes.
   Running Services:
       httpd on
       varnishd on
       sshd on
       Using 7 of 100 MaxClients

Initial Design Ideas

Though not yet proposed in Blueprints, these are some of the initial thoughts for the project to help guide discussion:

  • A pluggable implementation to allow discovering:
    • OpenStack infrastructure (instances, networks, et al.)
    • Non-OpenStack Infrastructure (APIs for other clouds, nodes in a Chef server, vendor management interfaces)
    • External infrastructure: DNS ownership and configuration, SSL Certificate validity, etc.
    • Operating system and application configuration (See: Related Work)
    • Runtime information such as active processes and connections between systems.
  • An API service for tenants to make discovery requests.
  • A backend datastore to record the results of discoveries.

Related Work

  1. Ohai
  2. Facter
  3. Ansible facts.d/setup
  4. Devstructure Blueprint

Satori Resources