[openstack-dev] Configuration Discovery - Satori
Yang Shuo (Shuo)
shuo.yang at huawei.com
Tue Jan 28 23:13:34 UTC 2014
Looks an interesting idea. Would you envision Satori primarily as an migration tool? Let's use the following scenarios as an example to explore the scope in your mind.
Server1 is a physical server running a mail server service, and we would like migrate it onto a virtual server provisioned by our OpenStack cluster. In this case, would Satori be helpful?
Server2 is a VM that I manually installed after OpenStack provides me a VM with a basic Ubuntu 12.10 image (as I manually did a lot of things and did not follow the Infrastructure as code philosophy, I do not know where I am at now), I want Satori to examine the system and create a cookbook or a heat template for me. Is this the Satori's primary target case?
Server3 is an EC2 instance, and I want to migrate that instance to my OpenStack cluster. In this case, would Satori be helpful?
BTW, what does " Configuration monitoring " mean? Can you elaborate it?
Love to hear more about you thoughts.
From: Adrian Otto [mailto:adrian.otto at rackspace.com]
Sent: Tuesday, January 28, 2014 2:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Configuration Discovery - Satori
I'd like to introduce you to a team working on an interesting problem space. We would like to know what you think about Configuration Discovery. We plan to build a tool that aids in the process of automated configuration discovery.
At Rackspace we work with customers who have pre-existing infrastructure and software running in production. To help them with changes, migrations, or configuration management, we often have to determine what they have in-place already. We have some tools and knowledge in-house that we use now, but we would like to create something even better in the open that would integrate well with OpenStack ecosystem projects like Heat, Solum, Murano, etc...
The concept for the tool is simple. The inputs are facts we know about the current system (a username, API Key, URL, etc.) and the output is a set of structured configuration information. That information can be used for:
- Generating Heat Templates
- Solum Application creation/import
- Creation of Chef recipes/cookbooks, Puppet modules, Ansible playbooks, setup scripts, etc..
- Configuration analysis (compare this config with a catalog of best practices)
- Configuration monitoring (has the configuration changed?)
We would like to hear from anyone interested in this problem domain, start a conversation on how this fits in the OpenStack ecosystem, and start exploring possible use cases that would be useful for users and operators of OpenStack clouds.
For more information about the team, implementation, and prior art in this area, please see:
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev