|
| 1 | +=========================== |
| 2 | +Compute Node Identification |
| 3 | +=========================== |
| 4 | + |
| 5 | +Nova requires that compute nodes maintain a constant and consistent identity |
| 6 | +during their lifecycle. With the exception of the ironic driver, starting in |
| 7 | +the 2023.1 release, this is achieved by use of a file containing the node |
| 8 | +unique identifier that is persisted on disk. Prior to 2023.1, a combination of |
| 9 | +the compute node's hostname and the :oslo.config:option:`host` value in the |
| 10 | +configuration file were used. |
| 11 | + |
| 12 | +The 2023.1 and later compute node identification file must remain unchanged |
| 13 | +during the lifecycle of the compute node. Changing the value or removing the |
| 14 | +file will result in a failure to start and may require advanced techniques |
| 15 | +for recovery. The file is read once at `nova-compute`` startup, at which point |
| 16 | +it is validated for formatting and the corresponding node is located or |
| 17 | +created in the database. |
| 18 | + |
| 19 | +.. note:: |
| 20 | + |
| 21 | + Even after 2023.1, the compute node's hostname may not be changed after |
| 22 | + the initial registration with the controller nodes, it is just not used |
| 23 | + as the primary method for identification. |
| 24 | + |
| 25 | +The behavior of ``nova-compute`` is different when using the ironic driver, |
| 26 | +as the (UUID-based) identity and mapping of compute nodes to compute manager |
| 27 | +service hosts is dynamic. In that case, no single node identity is maintained |
| 28 | +by the compute host and thus no identity file is read or written. Thus none |
| 29 | +of the sections below apply to hosts with :oslo.config:option:`compute_driver` |
| 30 | +set to `ironic`. |
| 31 | + |
| 32 | +Self-provisioning of the node identity |
| 33 | +-------------------------------------- |
| 34 | + |
| 35 | +By default, ``nova-compute`` will automatically generate and write a UUID to |
| 36 | +disk the first time it starts up, and will use that going forward as its |
| 37 | +stable identity. Using the :oslo.config:option:`state_path` |
| 38 | +(which is ``/var/lib/nova`` on most systems), a ``compute_id`` file will be |
| 39 | +created with a generated UUID. |
| 40 | + |
| 41 | +Since this file (and it's parent directory) is writable by nova, it may be |
| 42 | +desirable to move this to one of the other locations that nova looks for the |
| 43 | +identification file. |
| 44 | + |
| 45 | +Deployment provisioning of the node identity |
| 46 | +-------------------------------------------- |
| 47 | + |
| 48 | +In addition to the location mentioned above, nova will also search the parent |
| 49 | +directories of any config file in use (either the defaults or provided on |
| 50 | +the command line) for a ``compute_id`` file. Thus, a deployment tool may, on |
| 51 | +most systems, pre-provision the node's UUID by writing one to |
| 52 | +``/etc/nova/compute_id``. |
| 53 | + |
| 54 | +The contents of the file should be a single UUID in canonical textual |
| 55 | +representation with no additional whitespace or other characters. The following |
| 56 | +should work on most Linux systems: |
| 57 | + |
| 58 | +.. code-block:: shell |
| 59 | +
|
| 60 | + $ uuidgen > /etc/nova/compute_id |
| 61 | +
|
| 62 | +.. note:: |
| 63 | + |
| 64 | + **Do not** execute the above command blindly in every run of a deployment |
| 65 | + tool, as that will result in overwriting the ``compute_id`` file each time, |
| 66 | + which *will* prevent nova from working properly. |
| 67 | + |
| 68 | +Upgrading from pre-2023.1 |
| 69 | +------------------------- |
| 70 | + |
| 71 | +Before release 2023.1, ``nova-compute`` only used the hostname (combined with |
| 72 | +:oslo.config:option:`host`, if set) to identify its compute node objects in |
| 73 | +the database. When upgrading from a prior release, the compute node will |
| 74 | +perform a one-time migration of the hostname-matched compute node UUID to the |
| 75 | +``compute_id`` file in the :oslo.config:option:`state_path` location. |
| 76 | + |
| 77 | +.. note:: |
| 78 | + |
| 79 | + It is imperative that you allow the above migration to run and complete on |
| 80 | + compute nodes that are being upgraded. Skipping this step by |
| 81 | + pre-provisioning a ``compute_id`` file before the upgrade will **not** work |
| 82 | + and will be equivalent to changing the compute node UUID after it has |
| 83 | + already been created once. |
0 commit comments