[openstack-dev] [ironic][tests] approach to functional/integration tests

Dmitry Tantsur dtantsur at redhat.com
Tue Jan 12 09:45:20 UTC 2016

On 01/11/2016 03:49 PM, Serge Kovaleff wrote:
> Hi All,
> Last week I had a noble goal to write "one-more" functional test in Ironic.
> I did find a folder "func" but it was empty.
> Friends helped me to find a WIP patch
> https://review.openstack.org/#/c/235612/
> and here comes the question of this email: what approach we would like
> to implement:
> Option 1 - write infrastructure code that starts/configure/stops the
> services
> Option 2 - rely on installed DevStack and run the tests over it
> Both options have their Cons and Pros. Both options are implemented
> across the OpenStack umbrella.
> Option 1 - Glance, Nova, the patch above
> Option 2 - HEAT and my favorite at the moment.
> Any ideas?

I think we should eventually end up with supporting both standalone 
functional tests (#1) and tempest-based (#3).

A bit of context on #1. We've been using it in ironic-inspector since 
nearly its inception, when devstack plugins didn't exist and our project 
was on stackforge, so we had no way of implementing our dsvm gate. The 
basic idea is to start a full-featured service with mocked access to 
other services and simplified environment. We've written a decorator [1] 
that starts the service in __enter__ and stops in __exit__. It uses a 
temporary configuration file [2] with authentication disabled and 
database in temporary SQLite file. The service is started in a new green 
thread and exits when the test exits. We mock ironicclient with the 
usual 'mock' library to avoid requirements on a running ironic instance.

We do 2 kinds of tests: just an API test like [3] or full-flow 
introspection tests like [4]. In the latter case we first start 
introspection via API, verify that status is "in progress", then call 
the ramdisk callback endpoint with a fake data, and verify that 
introspection ends successfully.

Applying the same thing to ironic might be somewhat trickier. We can run 
conductor and API in the same process and use oslo.messaging fake driver 
[5] to avoid AMQP dependency. We'll have to use a fake network 
implementation and either mock glance or make sure we use local file 
system URL's for all images (IIRC we do support it).

Going further, if we create a simple fake IPA, we can even do a 
full-flow test with fake_agent driver. We will start deployment, make 
sure fake IPA was called with a right image, make it report success and 
see deployment finish. We might want to modify fake interfaces to record 
all calls, so that we can verify that boot interface was called properly.

[5] http://docs.openstack.org/developer/oslo.messaging/drivers.html#fake

> Cheers,
> Serge Kovaleff
> http://www.mirantis.com <http://www.mirantis.com/>
> cell: +38 (063) 83-155-70
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list