[openstack-dev] Configuration Discovery - Satori
Russell Bryant
rbryant at redhat.com
Tue Jan 28 23:08:30 UTC 2014
On 01/28/2014 06:02 PM, Jay Pipes wrote:
> On Tue, 2014-01-28 at 22:36 +0000, Adrian Otto wrote:
>> OpenStack Devs,
>>
>> 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?)
>> - Troubleshooting
>>
>> 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:
>>
>> https://wiki.openstack.org/wiki/Satori
>
> In the Related Work section, you list:
>
> Devstructure Blueprint (https://github.com/devstructure/blueprint)
>
> That is precisely what I would recommend. I don't see value in having a
> separate OpenStack project that does this.
Sometimes the right answer is to join in and help extend an existing
project. :-)
If that's *not* the answer, there should be a compelling reason why.
--
Russell Bryant
More information about the OpenStack-dev
mailing list