Ironic node auto-discovery
This spec proposes to start discuss general design way on auto-discovery feature and proposes some ideas and ways how it could be done. Co-Authored-By: Sam Betts <sam@code-smash.net> Related-Bug: #1524753 Change-Id: Ibc3097230f29dc7d882918531d20d47b083fbe32
This commit is contained in:
parent
176de0837c
commit
1ca7c413c3
|
@ -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