root / doc / design-bulk-create.rst @ 8c5419ee
History | View | Annotate | Download (3.2 kB)
1 |
================== |
---|---|
2 |
Ganeti Bulk Create |
3 |
================== |
4 |
|
5 |
.. contents:: :depth: 4 |
6 |
.. highlight:: python |
7 |
|
8 |
Current state and shortcomings |
9 |
============================== |
10 |
|
11 |
Creation of instances happens a lot. A fair load is done by just |
12 |
creating instances and due to bad allocation shifting them around later |
13 |
again. Additionally, if you turn up a new cluster you already know a |
14 |
bunch of instances, which need to exists on the cluster. Doing this |
15 |
one-by-one is not only cumbersome but might also fail, due to lack of |
16 |
resources or lead to badly balanced clusters. |
17 |
|
18 |
Since the early Ganeti 2.0 alpha version there is a ``gnt-instance |
19 |
batch-create`` command to allocate a bunch of instances based on a json |
20 |
file. This feature, however, doesn't take any advantages of iallocator |
21 |
and submits jobs in a serialized manner. |
22 |
|
23 |
|
24 |
Proposed changes |
25 |
---------------- |
26 |
|
27 |
To overcome this shortcoming we would extend the current iallocator |
28 |
interface to allow bulk requests. On the Ganeti side, a new opcode is |
29 |
introduced to handle the bulk creation and returning the resulting |
30 |
placement from the IAllocator_. |
31 |
|
32 |
|
33 |
Problems |
34 |
-------- |
35 |
|
36 |
Due to the design of chained jobs, we can guarantee, that with the state |
37 |
at which the ``multi-alloc`` opcode is run, all of the instances will |
38 |
fit (or all won't). But we can't guarantee that once the instance |
39 |
creation requests were submit, no other jobs have sneaked in between. |
40 |
This might still lead to failing jobs because the resources have changed |
41 |
in the meantime. |
42 |
|
43 |
|
44 |
Implementation |
45 |
============== |
46 |
|
47 |
|
48 |
IAllocator |
49 |
---------- |
50 |
|
51 |
A new additional ``type`` will be added called ``multi-allocate`` to |
52 |
distinguish between normal and bulk operation. For the bulk operation |
53 |
the ``request`` will be a finite list of request dicts. |
54 |
|
55 |
If ``multi-allocate`` is declared, ``request`` must exist and is a list |
56 |
of ``request`` dicts as described in :doc:`Operation specific input |
57 |
<iallocator>`. The ``result`` then is a list of instance name and node |
58 |
placements in the order of the ``request`` field. |
59 |
|
60 |
In addition, the old ``allocate`` request type will be deprecated and at |
61 |
latest in Ganeti 2.8 incooperated into this new request. Current code |
62 |
will need slight adaption to work with the new request. This needs |
63 |
careful testing. |
64 |
|
65 |
|
66 |
OpInstanceBulkAdd |
67 |
----------------- |
68 |
|
69 |
We add a new opcode ``OpInstanceBulkAdd``. It receives a list of |
70 |
``OpInstanceCreate`` on the ``instances`` field. This is done to make |
71 |
sure, that these two loosely coupled opcodes do not get out of sync. On |
72 |
the RAPI side, however, this just is a list of instance create |
73 |
definitions. And the client is adapted accordingly. |
74 |
|
75 |
The opcode itself does some sanity checks on the instance creation |
76 |
opcodes which includes: |
77 |
|
78 |
* ``mode`` is not set |
79 |
* ``pnode`` and ``snodes`` is not set |
80 |
* ``iallocator`` is not set |
81 |
|
82 |
Any of the above error will be aborted with ``OpPrereqError``. Once the |
83 |
list has been verified it is handed to the ``iallocator`` as described |
84 |
in IAllocator_. Upon success we then return the result of the |
85 |
IAllocator_ call. |
86 |
|
87 |
At this point the current instance allocation would work with the |
88 |
resources available on the cluster as perceived upon |
89 |
``OpInstanceBulkAdd`` invocation. However, there might be corner cases |
90 |
where this is not true as described in Problems_. |
91 |
|
92 |
|
93 |
.. vim: set textwidth=72 : |
94 |
.. Local Variables: |
95 |
.. mode: rst |
96 |
.. fill-column: 72 |
97 |
.. End: |