Open Stack

On January 28, 2014 at 5:18:42 PM, Yang Shuo (Shuo) (shuo.yang at huawei.com(mailto://shuo.yang@huawei.com)) wrote:

> Andrian,
>  
> 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.

Migrations are not the primary use case that we are targeting.

Primarily, Satori aims to discover as much detail as possible for an existing configuration. Imagine walking into a clients office with the mission to optimize the performance of domain.com. One of the first steps is to understand how the current environment is configured. Satori would give you a quick snapshot of all of the related systems in use. This includes:
- DNS settings
- SSL certificate details
- Load balancer settings and status of the connection pool
- Nova instances in the connection pool and piles of relevant info (OS, software installed, active connections to other nova/trove instances, etc).

Imagine the client handing you a Visio diagram of the discovered configuration for the entire site that isn’t 6 months old and several major changes behind reality :)

> 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?

The hardest part of the migration is dealing with the existing data. Satori could inspect the server and provide details of how it is configured but it wouldn’t seek to promise you a one-click migration that includes moving all of your data.

> 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?

This is a valid use case that we would target. However, a single server probe is handled very well by Devstructure’s Blueprint already. We would provide value in more complicated scenarios where several OpenStack resources and services are in use. The generated Heat template would provision the servers and the associated resources (queue, cinder volumes, trove database, etc).

> Server3 is an EC2 instance, and I want to migrate that instance to my OpenStack cluster. In this case, would Satori be helpful?

This feels very similar to your first use case.

> BTW, what does " Configuration monitoring " mean? Can you elaborate it?

Configuration monitoring is the passive detection of changes between discovery attempts. Monitoring is probably the wrong word as it implies constant polling. We could store and diff the results of multiple discovery runs.

>  
> Love to hear more about you thoughts.
>  
> Thanks,
> Shuo
>  

I hope this helps distinguish Satori and a single server reverse engineering project like Blueprint.

Caleb