docs: augment admin troubleshooting docs for system scope context

Change-Id: I55d94e40e0cc11106b8f0622355db0011e811622
This commit is contained in:
Julia Kreger 2024-02-06 14:09:40 -08:00
parent 5f4b964dd7
commit 325c2b0a96

View File

@ -1148,3 +1148,94 @@ i.e. a larger value to enable conductors to have time between running syncs.
merger will result in a slightly more performant implementation, which may merger will result in a slightly more performant implementation, which may
necessitate re-evaluation and tuning of the ``[pxe_filter]sync_period`` necessitate re-evaluation and tuning of the ``[pxe_filter]sync_period``
parameter. parameter.
Some or all of my baremetal nodes disappeared! Help?!
=====================================================
If you just upgraded, and this has occured:
#) Don't Panic
#) Don't try to re-enroll the nodes. They should still be there,
you just can't see them at the moment.
Over the past few years, Ironic and OpenStack project as a whole has been
working to improve the model of Role Based Access Control. For users of
Ironic, this means an extended role based access control model allowing
delineation of nodes and the ability for projects to both self-manage.
The result is that users inside of a project are only permitted to see
baremetal nodes, through the ``owner`` and ``lessee`` field, which has
been granted access to the project.
However, as with any complex effort, there can be hiccups, and you have
encountered one. Specifically that based upon large scale operator feedback,
Ironic kept logic behind System scoped user usage, which OpenStack largely
avoided due to concerns over effort.
As such, you have a couple different paths you can take, and your ideal
path is also going to vary upon your model of usage and comfort level.
We recommend reading the rest of this answer section before taking any
further action.
A good starting point is obtaining a ``system`` scoped account with an
``admin`` or ``member`` role. Either of those roles will permit a node's
``owner`` or ``lessee`` fields to be changed. Executing
``baremetal node list`` commands with this account should show you all
baremetal nodes accross all projects. Alternatively, If you just want to
enable the legacy RBAC policies temporarily to change the fields, that is also
an option, although not encouraged, and can be done utilizing the
``[oslo_policy] enforce_scope`` and ``[oslo_policy] enforce_new_defaults``
settings.
System Scoped Accounts
----------------------
A ``system`` scoped account is one which has access and authority over the
whole of the of an OpenStack deployment. A simplified way to think of
this is when deployed, a username and password is utilized to "bootstrap"
keystone. The rights granted to that user are inherently a system scoped
``admin`` role level of access. You can use this level of access to
check the status, or run additional commands.
In this example below, which if successful, should return a list of all
baremetal nodes known to Ironic, once the executing user supplies the
valid password. In this case the "admin" account keystone was
bootstrapped with. As a minor note, you will not be able to have
any "OS_*" enviornment variables loaded into your current
command shell, including "OS_CLOUD" for this command to be successful.
.. code-block:: console
$ openstack --os-username=admin --os-user-domain-name=default --os-system-scope all baremetal node list
You can alternatively issue a `system-scoped token <https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#operation_create_system_token>`_
and re-use further commands with that token, or even generate a new system
scoped account with a role of ``member``.
Changing/Assigning an Owner
---------------------------
Ironic performs matching based upon Project ID. The owner field can be set
to a project's ID value, which allows baremetal nodes to be visible.
.. code-block:: console
$ PROJECT_ID=$(openstack project show -c id -f value $PROJECT_NAME)
$ baremetal node set --owner $PROJECT_ID $NODE_UUID_OR_NAME
Why am I only seeing *some* of the nodes?
-----------------------------------------
During the Zed development cycle of Ironic, Ironic added an option which
defaulted to True, which enabled project scoped ``admin`` users to be able
to create their own baremetal nodes without needing higher level acccess.
This default enabled option, ``[api] project_admin_can_manage_own_nodes``,
automatically stamps the requestor's project ID on to a baremetal node if an
``owner`` is not otherwise specified upon creation. Obviously, this can
create a mixed perception if an operator never paid attention to the ``owner``
field before now.
If your bare metal management processes require that full machine management
is made using a project scoped account, please configure an appropriate
node ``owner`` for the nodes which need to be managed. Ironic recognizes
this is going to vary based upon processes and preferences.