Jump to: navigation, search

Difference between revisions of "Satori"

(init)
 
(Initial thoughts prior to project announcement)
Line 3: Line 3:
 
= OpenStack Configuration Discovery =
 
= OpenStack Configuration Discovery =
  
−
The mission of the OpenStack Configuration Discovery program is to...
+
The mission of the OpenStack Configuration Discovery project is to discover existing configurations. 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.
  
−
= Waldo =
+
== Use Cases ==
  
−
Waldo is...
+
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)
 +
* 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:
 +
 
 +
$ waldo discover www.foo.com
 +
Domain: foo.com
 +
    Registered at TUCOWS DOMAINS INC.
 +
    Expires in 475 days.
 +
    Name servers:
 +
        DNS1.STABLETRANSIT.COM
 +
        DNS2.STABLETRANSIT.COM   
 +
Address:
 +
    www.foo.com resolves to IPv4 address 4.4.4.4
 +
Host:
 +
    4.4.4.4 (www.foo.com) is hosted on a Nova Instance
 +
    Instance Information:
 +
        URI: https://nova.api.somecloud.com/v2/111222/servers/d9119040-f767-414
 +
            1-95a4-d4dbf452363a
 +
        Name: sampleserver01.foo.com
 +
        ID: d9119040-f767-4141-95a4-d4dbf452363a
 +
    ip-addresses:
 +
        public:
 +
            ::ffff:404:404
 +
            4.4.4.4
 +
        private:
 +
            10.1.1.156
 +
    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 127.0.0.1:8080
 +
        varnishd on 0.0.0.0:80
 +
        sshd on 0.0.0.0:22
 +
    httpd:
 +
        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 ([https://github.com/opscode/ohai Chef Ohai], [http://projects.puppetlabs.com/projects/facter Puppet Facter], [http://devstructure.com/blueprint/ Devstructure Blueprint], etc)
 +
** Runtime information such as active processes and connections between systems.
 +
* An API service for tenants to request discovery requests.
 +
* A backend datastore to record the results of discoveries.

Revision as of 23:21, 27 January 2014


OpenStack Configuration Discovery

The mission of the OpenStack Configuration Discovery project is to discover existing configurations. 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.

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)
  • 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: 

$ waldo discover www.foo.com
Domain: foo.com
   Registered at TUCOWS DOMAINS INC.
   Expires in 475 days.
   Name servers:
       DNS1.STABLETRANSIT.COM
       DNS2.STABLETRANSIT.COM    
Address:
   www.foo.com resolves to IPv4 address 4.4.4.4
Host:
   4.4.4.4 (www.foo.com) is hosted on a Nova Instance
   Instance Information:
       URI: https://nova.api.somecloud.com/v2/111222/servers/d9119040-f767-414
            1-95a4-d4dbf452363a
       Name: sampleserver01.foo.com
       ID: d9119040-f767-4141-95a4-d4dbf452363a
   ip-addresses:
       public:
           ::ffff:404:404
           4.4.4.4
       private:
           10.1.1.156
   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 127.0.0.1:8080
       varnishd on 0.0.0.0:80
       sshd on 0.0.0.0:22
   httpd:
       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 (Chef Ohai, Puppet Facter, Devstructure Blueprint, etc)
    • Runtime information such as active processes and connections between systems.
  • An API service for tenants to request discovery requests.
  • A backend datastore to record the results of discoveries.
Retrieved from "https://wiki.openstack.org/w/index.php?title=Satori&oldid=40600"