Allow Leasable Nodes¶
A large bare metal deployment may consist of hardware owned by multiple
owners who lease their nodes to users - lessees - who gain temporary and
limited access to specific nodes. Ironic understands the concept of a
hardware owner: a node can set its
owner field to a project, and that
project can gain API access to that node through the use of an updated
policy file. However, Ironic does not understand the concept of a node
This spec describes a solution that accommodates the notion of a node lessee.
Ironic currently supports two classes of users: administrators, who control the entire inventory of hardware; and owners, who have policy-limited API access to the nodes that they own. However, Ironic does not support non-administrative users - users who can deploy upon a node, and perhaps have access to an extremely limited subset of the API (such as node power functions).
Node lessees can be supported with the following changes:
Add a new
lesseefield to the node object. This field must either be empty or set to a Keystone project id.
Update the node controller so that policy checks pass in a node’s
lesseeinformation. Note that Ironic already does that with node owners .
Update Ironic’s default generated policy file to include an
The remainder of the policy file will stay the same, so that there is no change to default API access.
Update the node list function so that projects with access to
baremetal:node:listare returned nodes with matching
Update Ironic allocations so that allocations with owners can match nodes by a node’s
Note that this work does not add any new scheduling responsibilities in
Ironic. A new Nova filter, such as an updated version of the
proposed NodeOwnerFilter , would be desirable; and Blazar could
integrate with the
lessee field as they see fit. However, the
proposed work does integrate well with the existing ability to create
a restricted allocation.
Further down the line when Ironic creates a Deployment API, we can have the new Deployment API actions default to being accessible to node lessees.
Lessee information could be stored in a dictionary field such as
extras. However this makes updating database queries
far more difficult, and the non-administrative user concept feels distinct
enough to warrant a new field.
Data model impact¶
lessee field will be added to the nodes table as a
with a default value of
State Machine Impact¶
REST API impact¶
lesseefield will be returned with the node object.
The REST API will pass in the
lesseefor node policy checks.
The API will be updated to allow a user to set/unset the value through the API.
The node list API will be updated to allow filtering by
baremetal:node:listaction will be updated to match nodes by both lessee and owner.
A new API microversion will be introduced for the new node
Client (CLI) impact¶
“openstack baremetal” CLI¶
An update will be needed to enable a user to set/unset
lessee from the
RPC API impact¶
Driver API impact¶
Nova driver impact¶
This change allows functionality to be exposed to additional users. However this access is blocked off by default; it requires an update to the Oslo policy file, and can be adjusted as an administrator desires.
Other end user impact¶
Some functionality that previously matched nodes by
owner will now
have to match both
lessee. This should be doable at
the database query level.
Other deployer impact¶
Primary assignees: * tzumainn - firstname.lastname@example.org
Add database field.
Add object field.
Add REST API functionality and microversion.
Update REST API documentation.
Update node controller.
Update allocations conductor.
Write documentation detailing usage.
We will add unit tests and Tempest tests.
Upgrades and Backwards Compatibility¶
lessee node field will be created as part of the upgrade process
with a default value in the database schema. This change has no end-user
impact if the policy file is not updated.
REST API documentation will be updated.