[openstack-dev] Configuration Discovery - Satori

Adrian Otto adrian.otto at rackspace.com
Wed Jan 29 05:57:16 UTC 2014


Hi Jay,

On Jan 28, 2014, at 4:23 PM, Jay Pipes <jaypipes at gmail.com>
 wrote:

> On Tue, 2014-01-28 at 17:20 -0600, Caleb Groom wrote:
>> On January 28, 2014 at 5:05:56 PM, Jay Pipes (jaypipes at gmail.com)
>> wrote:
>>> 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.
>>> 
>>> Best,
>>> -jay
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> Hi Jay,
>> 
>> 
>> Devstructure Blueprint is scoped to gathering information about a
>> single server. We listed it as related because its a handy way to
>> handle reverse engineering once you’re logged into a server instance.
>> However, Satori has greater aims such as discovering the topology of
>> resources (load balancer, its configuration, nova instances behind the
>> load balancer, connected cinder instances, etc). For each relevant
>> server instance we could gather deep system knowledge by using the
>> projects listed in the Related section.
> 
> So why not improve Devstructure Blueprint and add in some plugins that,
> given some OpenStack creds, query things like the Neutron and Nova API
> endpoints for such information.

If that approach would yield the right balance of open collaboration that we are seeking, that's an option that can certainly be revisited. We have learned from experience that organizing development around an open collaboration can yield some very good results. Contributing to existing projects may help us advance on the mission, but it may not be as effective as leveraging all of our lessons learned about how to work in the open. I think this particular concept is more ambitious than the existing work, and may demand a good deal of attention from the current maintainers.

> I don't think this needs to be a separate OpenStack service.

Oh, neither does the Satori team! We are in complete agreement. This is a vision for a tool intended to help OpenStack Cloud operators work more easily, troubleshoot more quickly, etc. It does not need to be a service at all to achieve that.

Cheers,

Adrian

> 
> Best,
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list