OpenStack - User contributions [en]

Satori/Specialize-in-Tripple-O-Discovery

2014-04-03T12:59:28Z

GusMaskowitz:

WORK IN PROGRESS - "poc-tripple-o-discovery"

Blueprint:
https://blueprints.launchpad.net/satori/+spec/satori-specialize-in-tripple-o

Summary:
For OpenStack administrators it could be valuable to sanity-check their OpenStack configs using a tool like Satori.

That would be simple where OpenStack is run ON OpenStack (Tripple-O). In such cases Satori can easily discover control-plane and data-plane details. Then we can apply opinions from other OpenStack administrators/engineering teams rather than rely on technical documentation.

Having technical documentation/process codified and actively working for humans is one of the major goals of satori for tenants of OpenStack clouds. Let's specialize to help OpenStack administrators get good help from other admins to make running a cloud at scale a little bit simpler.

Why try?
Even with config management (which should be present in any proper web-scale cloud), there can be config in production that is not documented and affecting the performance of the system. Satori could become the silent, but always on "sanity checker" applying thing learned all over the world to your cloud in a very simple way.

This use case also makes Satori a part key of OpenStack, rather than just another tool for quality checking systems.

Satori/Specialize-in-Tripple-O-Discovery

2014-04-01T13:09:14Z

GusMaskowitz:

WORK IN PROGRESS - "poc-tripple-o-discovery"

Blueprint:
https://blueprints.launchpad.net/satori/+spec/satori-specialize-in-tripple-o

Summary:
For OpenStack administrators it would be incredibly valuable to "remember what others before them have learned" in terms of running a cloud at scale. Where OpenStack is run ON OpenStack (Tripple-O) Satori can do this by discovering config-plane and data-plane and apply opinions. This is one of the major goals of satori for tenants of OpenStack clouds. Let's specialize in the same way but help OpenStack *admins* stand on the shoulders of giants when they run OpenStack for others.

Why try?
With or without config management, there can be config in production that is not documented and affecting the performance of the system. If we go find it and apply best practises from all the admins in the world together, then each openstack cloud can be better.

Let's build the framework to capture that expertise and help more OpenStack clouds be run really really well.

This is possible with Satori - but I want us to specialize early so that there is more immediate help for OpenStack admins.

Satori/Specialize-in-Tripple-O-Discovery

2014-04-01T10:36:20Z

GusMaskowitz: Created page with "WORK IN PROGRESS - "poc-tripple-o-discovery""

WORK IN PROGRESS - "poc-tripple-o-discovery"

Satori

2014-03-18T15:25:06Z

GusMaskowitz: /* Getting Started */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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

Address:
www.foo.com resolves to IPv4 address 4.4.4.4
Domain: foo.com
Registered at TUCOWS DOMAINS INC.
Expires in 475 days.
Name servers:
DNS1.STABLETRANSIT.COM
DNS2.STABLETRANSIT.COM
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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* [https://wiki.openstack.org/wiki/Satori/glossary Glossary]
* IRC: <code>#openstack-satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori

2014-03-11T20:53:54Z

GusMaskowitz: /* Getting Started */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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 discover www.foo.com

Address:
www.foo.com resolves to IPv4 address 4.4.4.4
Domain: foo.com
Registered at TUCOWS DOMAINS INC.
Expires in 475 days.
Name servers:
DNS1.STABLETRANSIT.COM
DNS2.STABLETRANSIT.COM
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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* [https://wiki.openstack.org/wiki/Satori/glossary Glossary]
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori

2014-03-11T20:53:22Z

GusMaskowitz: /* Getting Started */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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 discover www.foo.com
Address:
www.foo.com resolves to IPv4 address 4.4.4.4
Domain: foo.com
Registered at TUCOWS DOMAINS INC.
Expires in 475 days.
Name servers:
DNS1.STABLETRANSIT.COM
DNS2.STABLETRANSIT.COM
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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* [https://wiki.openstack.org/wiki/Satori/glossary Glossary]
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori

2014-03-10T15:30:28Z

GusMaskowitz: /* Satori Resources */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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 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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* [https://wiki.openstack.org/wiki/Satori/glossary Glossary]
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori/glossary

2014-03-10T15:16:53Z

GusMaskowitz: /* Configuration Discovery Terms */

=== Configuration Discovery Terms ===
:<big>The following terms are used to describe discovery more narrowly and differentiate configuration discovery concepts, while in combination they specify much of what Satori aims to accomplish.</big>

==== Control Plane Discovery ====
:Using native bindings, client libraries ([https://github.com/rackspace/pyrax pyrax], [https://github.com/boto/boto boto], [https://github.com/openstack/python-novaclient novaclient], [https://github.com/apache/libcloud libcloud], [https://www.destroyallsoftware.com/talks/wat etc.]) or cloud APIs to attain information about a configuration. This requires credentials/api tokens, and could provide: a server's image data, a server's region, a load-balancer's VIPs and nodes, networking info, etc.

==== Data Plane Discovery ====
:Making direct observations about a configuration by running commands/utilities directly on the system, or accessing and analyzing a system's network interface. This might require login credentials for the host resource, and could provide information ranging from disk usage to packages installed to motherboard fan speeds.

==== SysInfo Provider ====
:One of any open source applications or utilities that will examine a host machine and return verbose information about that system. Satori will leverage/support these tools for Data Plane Discovery.

Satori/glossary

2014-03-10T13:30:55Z

GusMaskowitz: /* Configuration Discovery Terms */

Satori

2014-03-10T13:22:18Z

GusMaskowitz: /* Satori Resources */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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 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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* [https://wiki.openstack.org/wiki/Satori/glossary Glossary/Terminology]
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori

2014-03-06T22:36:53Z

GusMaskowitz: /* Quick overview */

= 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.

__TOC__

== Quick overview ==
* Source code https://github.com/stackforge/satori
* Feature tracker https://blueprints.launchpad.net/satori
* Bug tracker https://bugs.launchpad.net/satori/
* Developer doc http://satori.readthedocs.org/en/latest/

== 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 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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/stackforge/satori Source Code]
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]

Satori

2014-03-06T15:39:36Z

GusMaskowitz: /* OpenStack Configuration Discovery */

= 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.

__TOC__

== Quick overview ==
Source code https://github.com/stackforge/satori
Bug tracker https://bugs.launchpad.net/satori/
Feature tracker https://blueprints.launchpad.net/satori
Developer doc http://satori.readthedocs.org/en/latest/

== 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 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 (See: [[Satori#Related_Work|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 ==
# [https://github.com/opscode/ohai Ohai]
# [https://github.com/puppetlabs/facter Facter]
# Ansible [https://github.com/ansible/ansible/blob/devel/library/system/setup#L101 facts.d/setup]
# Devstructure [https://github.com/devstructure/blueprint Blueprint]

== Satori Resources ==
* [https://launchpad.net/satori Satori on LaunchPad] (Blueprints, and bugs)
* [https://launchpad.net/~satori-drivers The Team (Join us!)]
* [https://github.com/rackerlabs/satori Source Code] (to be moved to Stackforge soon)
* IRC: <code>#satori</code> on [http://freenode.net/ Freenode] for development discussion.
* [[Meetings/Satori|Weekly meeting schedule]], [[Satori/MeetingLogs|Previous meetings]]