Allow Leasable Nodes

https://storyboard.openstack.org/#!/story/2006506

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 lessee.

This spec describes a solution that accommodates the notion of a node lessee.

Problem description

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).

Proposed change

Node lessees can be supported with the following changes:

  • Add a new lessee field 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 lessee information. Note that Ironic already does that with node owners [0].

  • Update Ironic’s default generated policy file to include an is_node_lessee rule:

    • “is_node_lessee”: “project_id:%(node.lessee)s”

    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:list are returned nodes with matching owner or lessee fields.

  • Update Ironic allocations so that allocations with owners can match nodes by a node’s owner or lessee.

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 [1], 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.

Alternatives

Lessee information could be stored in a dictionary field such as properties or 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

A lessee field will be added to the nodes table as a VARCHAR(255) with a default value of null.

State Machine Impact

None

REST API impact

  • A lessee field will be returned with the node object.

  • The REST API will pass in the lessee for 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 lessee.

  • The limited baremetal:node:list action will be updated to match nodes by both lessee and owner.

  • A new API microversion will be introduced for the new node lessee field.

Client (CLI) impact

None

“ironic” CLI

None

“openstack baremetal” CLI

An update will be needed to enable a user to set/unset lessee from the command line.

RPC API impact

None

Driver API impact

None

Nova driver impact

None

Ramdisk impact

None

Security 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

None

Scalability impact

None

Performance Impact

Some functionality that previously matched nodes by owner will now have to match both owner and lessee. This should be doable at the database query level.

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignees: * tzumainn - tzumainn@redhat.com

Work Items

  • Add database field.

  • Add object field.

  • Add REST API functionality and microversion.

  • Update REST API documentation.

  • Update python-ironicclient.

  • Update node controller.

  • Update allocations conductor.

  • Write tests.

  • Write documentation detailing usage.

Dependencies

None

Testing

We will add unit tests and Tempest tests.

Upgrades and Backwards Compatibility

The 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.

Documentation Impact

REST API documentation will be updated.

References