Open Stack

Hello, All.

Although quite new to OpenStack, we are thinking about enhancing the 
simulation/fake environment available for OpenStack development and 
testing.

Currently, OpenStack has an option to use a fake driver which enables 
testing of the management of very many instances without actually creating 
any of these instances. This has been a significant contribution to 
OpenStack quality (see 
http://dague.net/2013/10/21/openstack-havana-the-quality-perspective/).

Apparently, the current implementation of fake drivers allows creating 
instances regardless of hypervisor resources. This is useful in some test 
scenarios, but may not exercise enough code in others.

There are several directions in which the fake environment can be 
expanded. We'd like to get the community's feedback on them.
Enable and control fake hypervisors: add convenient interfaces to add and 
remove hypervisors and define their properties. Allow testing that takes 
into account hypervisors' fake resources.
Enable ping and ssh to the fake entities. We can use honeyd (
en.wikipedia.org/wiki/Honeyd) to intercept IP operations, and fake the 
results. ssh would be limited - we'd like to know what function is 
essential.
Enhance the fake entities to simulate metrics such as boot time, shutdown 
time, response time, CPU usage, etc.
Add error injection capabilities - crash, delay, ..?
Persist the state of the fake cloud, so that you can test what happens if 
your management crashes and you restart it, or an alternative. This 
includes finding a way to let the fake entities register on to the cloud.
Create fake entities that are outside of OpenStack, i.e., communication 
with them is really through the network, with real interfaces. One 
direction for implementing that may be taking Qemu and replacing all its 
innards.

The environment should support five major functions:
Setup: define the initial configuration of the fake cloud, including 
adding and removing physical resources
Execution: invoke operations such as operations on instances
Synchronization: invoke operations when conditions are observed
Injection: inject errors, including delays
Verification: verify that the cloud is in the expected state

Additionally, recreating scenarios should be possible whenever possible.

The main use cases we are aware of are:
Developer testing - is DevStack already enough?
Regression testing
Stress testing (for some components)
Bad path testing
Concurrency testing (we could make sure various operations occur in 
different interleavings)
Recovery testing

We'd like to learn more on OpenStack pain points from these perspectives.

Any thoughts? Advice?

Donny and Aviad
--------------------------------------------------------------------------------------------------------------------------------
Tel: +972-48-296-284, Cell: +972-546-976-284, Fax: +972-48-296-113, Email: 
aviad at il.ibm.com
 
Prediction is very difficult, especially if it's about the future. -- 
Niels Bohr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140112/b8d4cb6d/attachment.html>