4.3 KiB
Ownership Information Storage
https://storyboard.openstack.org/#!/story/2001814
In many large businesses with hardware fleets, there may be a variety of ownership of the underlying hardware for tracking purposes. A good example of this is in a hybrid service provider scenario where an operator may directly own a portion of the hardware, may have the hardware on lease, and may ultimately have customer owned hardware.
We simply cannot model this with existing node fields, since there may be resource sharing agreements also in place between the owners of the hardware. And as such, we need some way to store and represent the end owner of the hardware for tracking and logistical purposes.
Problem description
While scenarios differ, ultimately there is a need to be able to store information in a top level fashion about who owns a given piece of hardware.
Information of this sort can be vital when it comes time for tax asset inventories, or just simple tracking of where the hardware came from.
Providing the ability to search and return the hardware that is known to be owned by a particular group allows for faster correlation of the disposition of the hardware for auditing and accounting purposes.
Proposed change
Proposing to add a new informational field to the node object that can be queried via the REST API, and stored in the database. No other initial use of this field is expected.
Future use could also be automatic in the scenario if there is a driver that is aggregating a number of management systems, however that is out of scope.
Alternatives
An operator could potentially store this information in extra, however then they would still need to dump all of the nodes out to obtain a list of nodes with the specific information that is needed. The operator would begin to hit limits with the number of responses from the API, and would need to likely create their own tooling around list processing.
Data model impact
A owner field would be added to the nodes table as a
VARCHAR(255) and will have a default value of
null in the database.
State Machine Impact
None
REST API impact
An owner field will be returned as part of the node. The
API shall be updated to allow a user to set and unset the value via the
API.
Additionally the GET syntax for the nodes list will be updated to allow a list of matching nodes to be returned.
POST/PATCH operations to the field will be guarded by a new microversion. The field shall not be returned unless the sufficient microversion is supplied for GET operations.
Client (CLI) impact
"ironic" CLI
None
"openstack baremetal" CLI
A corresponding change will be necessary to enable the ability for a user to set/unset the value from a command line.
RPC API impact
None
Driver API impact
None
Nova driver impact
None
Ramdisk impact
None
Security impact
None
Other end user impact
None
Scalability impact
None
Performance Impact
None
Other deployer impact
None
Developer impact
None
Implementation
Assignee(s)
- Primary assignee:
-
TheJulia - juliaashleykreger@gmail.com
- Other contributors:
-
None
Work Items
- Add database field.
- Add object field.
- Add REST API functionality and microversion.
- Update REST API documentation.
- Update python-ironicclient.
Dependencies
None
Testing
Basic API CRUD testing will be added. There is no need for additional testing as this is an informational field for the API user/baremetal operator.
Upgrades and Backwards Compatibility
Field will be created as part of the upgrade process with a default value in the database schema.
Documentation Impact
REST API documentation will need to be updated.
References
None