Merge "Ironic node auto-discovery"
This commit is contained in:
commit
daf85dcc62
|
@ -0,0 +1,172 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=====================
|
||||
Discover ironic nodes
|
||||
=====================
|
||||
|
||||
https://bugs.launchpad.net/ironic-inspector/+bug/1524753
|
||||
|
||||
This spec proposes auto-discovery Ironic nodes feature.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
A large network might consist of hundreds of servers. Keeping track of these
|
||||
servers can be a time-consuming process. To simplify the addition of new
|
||||
servers could be done with auto-discovery. Auto-discovery is a process through
|
||||
which Ironic identifies a resource automatically so it's possible to manage it.
|
||||
For now, Ironic is unable to automatically detect nodes. Operators have to
|
||||
create nodes manually and provide driver info for them.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Nodes that don't exist in the inspector node cache may still be booted and
|
||||
return inspection information to process, ``node-not-found-hook`` allows to
|
||||
handle that information. For discovery new implementation called
|
||||
``enroll_node_not_found_hook`` should be specified. It will create a node
|
||||
with ``fake`` driver.
|
||||
|
||||
To customize discovery, introspection rules will be used, it allows operators
|
||||
to control the discovery process. A simple rule to match all new nodes and
|
||||
enroll them in Ironic with the ``agent_ipmitool`` driver will looks like::
|
||||
|
||||
"description": "Set IPMI driver_info if no address or credentials",
|
||||
"actions": [
|
||||
{'action': 'set-attribute', 'path': 'driver', 'value': 'agent_ipmitool'},
|
||||
{'action': 'set-attribute', 'path': 'driver_info/ipmi_address',
|
||||
'value': '{data[ipmi_address]}'},
|
||||
{'action': 'set-attribute', 'path': 'driver_info/ipmi_username',
|
||||
'value': 'username'},
|
||||
{'action': 'set-attribute', 'path': 'driver_info/ipmi_password',
|
||||
'value': 'password'}
|
||||
]
|
||||
"conditions": [
|
||||
{'op': 'eq', 'field': 'node://driver_info/ipmi_password',
|
||||
'multiple': 'all', 'value': None},
|
||||
{'op': 'eq', 'field': 'node://driver_info/ipmi_username',
|
||||
'multiple': 'all', 'value': None}
|
||||
]
|
||||
|
||||
|
||||
"description": "Set deploy info if not already set on node",
|
||||
"actions": [
|
||||
{'action': 'set-attribute', 'path': 'driver_info/deploy_kernel',
|
||||
'value': '<glance uuid>'},
|
||||
{'action': 'set-attribute', 'path': 'driver_info/deploy_ramdisk',
|
||||
'value': '<glance uuid>'},
|
||||
]
|
||||
|
||||
"conditions": [
|
||||
{'op': 'eq', 'field': 'node://driver_info/deploy_ramdisk',
|
||||
'multiple': 'all', 'value': None},
|
||||
{'op': 'eq', 'field': 'node://driver_info/deploy_kernel',
|
||||
'multiple': 'all', 'value': None}
|
||||
]
|
||||
|
||||
Rule changes:
|
||||
|
||||
- condition changes: extend field ``field``, for now it's represent
|
||||
a `JSON path`_ to the field in the introspection data to use in comparison.
|
||||
But sometimes it's needed to compare data from node(``deploy_ramdisk``
|
||||
compared with None in example), so to get data from node, ``node://``
|
||||
and ``data://`` scheme proposed to add. It will allow to fetch data using
|
||||
path from the nodes info and introspection(``data://`` is default scheme
|
||||
to keep backward compatibility)::
|
||||
|
||||
node://driver_info.deploy_ramdisk - ``deploy_ramdisk`` attribute from
|
||||
node's driver_info.
|
||||
data://memory_mb - ``memory_mb`` attribute from
|
||||
introspection data.
|
||||
|
||||
- actions changes: for now it's impossible to assign values from inspection
|
||||
data to node, to address this disadvantage it's proposed to add standard
|
||||
python formatting `Python format`_ to ``value`` field.
|
||||
For example, ``set-attribute`` sets an attribute on an Ironic node. It's
|
||||
required the ``path`` field, which is the path to the attribute in Ironic,
|
||||
e.g.``driver_info/ipmi_username``, and a ``value`` to set. Where ``value``
|
||||
is simple value, which assigned to path::
|
||||
|
||||
{data[ipmi_address]} - ``ipmi_address`` attribute from introspection
|
||||
data will be fetched.
|
||||
|
||||
Creating new actions will allow the node info to be consumed in different
|
||||
ways. Proposed approach is pretty flexible, so more sophisticated conditions
|
||||
and actions could be added here based on operators specifications.
|
||||
|
||||
Operator steps for achieve auto-discovery would be following:
|
||||
* Operator creates a new rule or uses the predefined ``discovery rule``;
|
||||
* Operator import rule to Inspector;
|
||||
* All nodes after rule is imported will be discovered with it.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Continue enroll nodes manually and run inspection. But it's not appropriate
|
||||
approach for big significant environments.
|
||||
|
||||
API impact
|
||||
----------
|
||||
|
||||
None
|
||||
|
||||
Performance and scalability impact
|
||||
----------------------------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Deployer impact
|
||||
---------------
|
||||
|
||||
Note: before discovery, the config option ``node_not_found_hook`` should be
|
||||
assigned to the ``enroll_node_not_found_hook`` value;
|
||||
deployers will be required to create rules, so they should be familiar
|
||||
with rules, rules conditions and actions; for simple cases example rules
|
||||
could be used.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Developers can create additional conditions and actions regarding their
|
||||
needs to extend the discovery process.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
* Anton Arefiev(aarefiev)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Extend conditions and actions to support proposed format;
|
||||
* Cover new functionality with unit and integration tests;
|
||||
* Add example rules;
|
||||
* Update docs.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Unit, functional and integration tests will be added.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. _`JSON path`: http://goessner.net/articles/JsonPath/
|
||||
.. _`Python format`: https://docs.python.org/3/library/stdtypes.html#str.format
|
Loading…
Reference in New Issue