Difference between revisions of "Satori/Specialize-in-Tripple-O-Discovery"

Latest revision as of 12:59, 3 April 2014

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.

@@ Line 6: / Line 6: @@
 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.
+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?
-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.
+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.
-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.
+This use case also makes Satori a part key of OpenStack, rather than just another tool for quality checking systems.