Recent changes to Confluent_discovery

Confluent_discovery modified by Guang Cheng Li

Guang Cheng Li — Mon, 04 Aug 2014 02:56:54 -0000

--- v2
+++ v3
@@ -1,3 +1,5 @@
+[[include ref=Design_Warning]]
+
 Confluent should expand the discovery facility present in xCAT 2.  The general flow is that things are divided into two pieces:

 1. detection.  Something being detected simply causes confluent to take note of it under the /detected/ collection and notify any 'discovery' handles of the new or updated entry

Confluent_discovery modified by Jarrod Johnson

Jarrod Johnson — Fri, 01 Aug 2014 15:46:52 -0000

--- v1
+++ v2
@@ -3,10 +3,35 @@
 1. detection.  Something being detected simply causes confluent to take note of it under the /detected/ collection and notify any 'discovery' handles of the new or updated entry
 2. discovery.  Classifiying a detected object as a known entity.  This could be an automated action due to switch or enclosure matching.  It could be a client application implementing a first-come, first-serve scheme to assign detected to existing nodes, or a client application creating nodes and then assigning them based on what is seen.   The first come, first serve model I think best implemented as a client utility rather than a server capability (shouldn't be full-time automatic)

+Detection
+=======================
+To the extent reasonable, this should be a non-intrusive collection of information about relevant targets.  A detected node is not told to boot anything or reconfigured at all.  Sometimes multiple sources will indicate different facets of a single node (e.g. PXE and service processor).  Those sources will merge into a single source of data.
+
 PXE detection
-==================================
+---------------------
 As per [Confluent_bootsupport] the intent is to bring in the facility to respond to DHCP requests.  Take advantage of the situation to detect a potentially actionable amount of data before the first OFFER is even sent.  Auto-detection could even occur before any boot directive sent to node.

+Boot image detection
+-------------------------
+If the above is insufficient or triggers an inquiry for more data, boot genesis.  This enables deeper exploration of a node, what network interfaces it has, and so on.  Unlike xCAT, where this always happens, have it be an option disabled by default.  The deeper inventory would likely be a result of 'discovery', but 'detection' will be less disruptive.  The ability to find a node by a non-boot NIC would require this feature be enabled, but searching server enclosures and switches would not require this most of the time.
+
 Vendor specific
-==================================
-Implement vendor-specific detection capabilities as appropriate for product.
+----------------------
+Implement vendor-specific detection capabilities as appropriate for product, service processors being high on list.
+
+Discovery
+=======================================
+
+Methods
+----------------------
+
+Same as xCAT:
+
+* snmp of switches
+* interrogation of server enclosure managers
+
+Actions
+--------------------------
+
+* For a compute node that is discovered, boot into Genesis for a deeper inventory followed by administrator defined 'chain' with a default of parking it in an sshable state for future action.
+* Other resources may have specific discovery responses coded into plugins.  For example, IMM would have a remote login and remote configure.

Confluent_discovery modified by Jarrod Johnson

Jarrod Johnson — Fri, 01 Aug 2014 15:33:52 -0000

Confluent should expand the discovery facility present in xCAT 2. The general flow is that things are divided into two pieces:

detection. Something being detected simply causes confluent to take note of it under the /detected/ collection and notify any 'discovery' handles of the new or updated entry
discovery. Classifiying a detected object as a known entity. This could be an automated action due to switch or enclosure matching. It could be a client application implementing a first-come, first-serve scheme to assign detected to existing nodes, or a client application creating nodes and then assigning them based on what is seen. The first come, first serve model I think best implemented as a client utility rather than a server capability (shouldn't be full-time automatic)

PXE detection

As per [Confluent_bootsupport] the intent is to bring in the facility to respond to DHCP requests. Take advantage of the situation to detect a potentially actionable amount of data before the first OFFER is even sent. Auto-detection could even occur before any boot directive sent to node.

Vendor specific

Implement vendor-specific detection capabilities as appropriate for product.