summaryrefslogtreecommitdiff
path: root/doc/source/admin/drivers/fake.rst
blob: 2e2cc355e40e04e985122306100394c261daab02 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
===========
Fake driver
===========

Overview
========

The ``fake-hardware`` hardware type is what it claims to be: fake. Use of this
type or the ``fake`` interfaces should be temporary or limited to
non-production environments, as the ``fake`` interfaces do not perform any of
the actions typically expected.

The ``fake`` interfaces can be configured to be combined with any of the
"real" hardware interfaces, allowing you to effectively disable one or more
hardware interfaces for testing by simply setting that interface to
``fake``.

Use cases
=========

Development
-----------
Developers can use ``fake-hardware`` hardware-type to mock out nodes for
testing without those nodes needing to exist with physical or virtual hardware.

Scale testing
-------------
The ``fake`` drivers have a configurable delay in seconds which will result in
those operations taking that long to complete. Two comma-delimited values will
result in a delay with a triangular random distribution, weighted on the first
value. These delays are applied to operations which typically block in other
drivers. This allows more realistic scenarios to be arranged for performance and
functional testing of an Ironic service without requiring real bare metal or
faking at the BMC protocol level.

.. code-block:: ini

    [fake]
    power_delay = 5
    boot_delay = 10
    deploy_delay = 60,360
    vendor_delay = 1
    management_delay = 5
    inspect_delay = 360,480
    raid_delay = 10
    bios_delay = 5
    storage_delay = 10
    rescue_delay = 120

Adoption
--------
Some OpenStack deployers have used ``fake`` interfaces in Ironic to allow an
adoption-style workflow with Nova. By setting a node's hardware interfaces to
``fake``, it's possible to deploy to that node with Nova without causing any
actual changes to the hardware or an OS already deployed on it.

This is generally an unsupported use case, but it is possible. For more
information, see the relevant `post from CERN TechBlog`_.

.. _`post from CERN TechBlog`: https://techblog.web.cern.ch/techblog/post/ironic-nova-adoption/