Open Stack

On January 28, 2014 at 6:23:14 PM, Jay Pipes (jaypipes at gmail.com(mailto://jaypipes@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.

That's a good question. Here's my current thinking:

- Blueprint is one method to obtain system information but there are alternatives. Chef's Ohai is particularly interesting because of its plugin structure and active community. Ohai is a standalone application that can be used without needing a server to be actively managed by Chef. My team has recently started to experiment with using Ohai without Chef [1]. Like Blueprint, it provides nice JSON output.
- Blueprint isn't under active development [2]. 
- The configuration management world is rapidly evolving. I believe that Satori should interact with them in a pluggable fashion so that the project's success isn't tied to any one specific vendor.
- Blueprint doesn't support Windows or Linux distributions outside of the Red Hat and Debian families. 
- The design of Blueprint assumes that you're executing commands against localhost only, making a server the center of the universe. However, I believe that there are several use cases for discovery where logging into the servers to fetch data would be nice to have but not required. The center of the universe could be the tenant ("show me everything about this tenant") or a website ("How is domain.com configured?"). Here's an example of discovery without accessing the servers:

-- domain.com resolves to 1.2.3.4.
-- That IP belongs to LBaaS instance xyz.
-- That LBaaS instance supports SSL termination and has 3 nova instances in the connection pool.
-- 2 of the 3 instances in the connection pool are offline.
-- A security group allows external connections to the public IPs of the nova instances.
-- The offline servers are build from a glance image that was updated today but the online server is 7 days old. 

I believe this is valuable information that can be provided to users and isn't near the current scope of Blueprint.

> 
> I don't think this needs to be a separate OpenStack service.
>  
> Best,
> -jay
>  

That's fair. Our intention today is to share our interest in the domain of discovery and our intention to work on this problem using open design, open development and open community. In time we'll solve some use cases that will hopefully make it more clear why we find this problem so interesting! We'll start writing Launchpad blueprints that will get get into more of the details.

Caleb 

[1] https://github.com/rackerlabs/ohai-plugins
[2] https://github.com/devstructure/blueprint/graphs/commit-activity