code.grnet.gr Git - ganeti-local/blob - doc/design-bulk-create.rst

   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: