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: [email protected] Prediction is very difficult, especially if it's about the future. -- Niels Bohr
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
