Bug 1422630

Summary: [RFE] As a Basic Deployer, I want the application to auto-discover nodes to make node registration quicker and less error prone.
Product: Red Hat OpenStack Reporter: Anandeep Pannu <apannu>
Component: rhosp-director-uiAssignee: Honza Pokorny <hpokorny>
Status: CLOSED WONTFIX QA Contact: Arik Chernetsky <achernet>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 12.0 (Pike)CC: achernet, beth.white, jbuchta, rhel-osp-director-maint, sclewis
Target Milestone: Upstream M2Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: NeedsAllocation
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-24 13:18:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420921, 1442136    

Description Anandeep Pannu 2017-02-15 17:54:00 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Anandeep Pannu 2017-02-15 17:57:40 UTC
From Ramon Acedo
Hi all,

Discovering nodes automatically via PXE booting on the provisioning network is currently not implemented in TripleO. When discussing this issue with Anandeep (Web UI), it turned out it’s also a high priority in their list.

To recap, with the current implementation in OSP 10, the operator (at least) needs to:

1. Collect node attributes (BMC)
2. Build file instackenv.json entering at least 3 [1] node attributes per node in the right JSON format.
3. Assign kernel and ramdisk images.
4. Run the necessary commands to do the inspection (per node or in bulk).
5. Set the nodes to available state.

On medium and large deployments this process is time consuming.

In general, some attributes will need to be passed ayway, different BMCs have different requirements and possibilities. Some implementations like the Ubuntu MAAS driver for IPMI create a user and a password from the discovery image with ipmitool in the BMC, which then are registered in their database, making process 100% transparent and reducing the operator work to having the nodes powered on. This is not possible with most of the other BMC drivers though (and some users may find it unsafe anyway) but the idea is to minimise the operator input as much as reasonably possible.

I have had customers familiar with Ubuntu MAAS [3] or Mirantis Fuel [4], who after a TripleO/director POC also bring this up (the last one I remember is Nokia), because both, MAAS and Fuel, implement it.

VMware have vSphere Auto Deploy [5] as a key feature for large states and they’ve been positioning it for a number of years (since vSphere 5.0 IIRC).

Red Hat Satellite can also be configured for auto-discovery of nodes [6].

An initial dependency landed in Mitaka [2], which can be used by TripleO/director as a first step towards full node auto-discovery in OSP, including the Web UI. You can track the initial work here [7].

We’d like to get your feedback on this effort, especially if you see any potential improvement or issue.

Thanks,

Ramon

[1] https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/single/director-installation-and-usage#sect-Registering_Nodes_for_the_Overcloud
[2] http://docs.openstack.org/developer/ironic-inspector/usage.html#discovery
[3] https://maas.ubuntu.com/docs/nodes.html#automatic-discovery
[4] https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#boot-the-node-servers
[5] https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005131
[6] https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.1/html/User_Guide/sect-Red_Hat_Satellite-User_Guide-Discovering_Bare_metal_Hosts_on_Satellite-Provisioning_Discovered_Hosts.html#sect-Red_Hat_Satellite-User_Guide-Provisioning_Discovered_Hosts-Automatically_Provisioning_Hosts
[7] https://bugzilla.redhat.com/show_bug.cgi?id=1362361#c5

Comment 2 Anandeep Pannu 2017-02-15 17:59:18 UTC
Nodes auto discovery  [spec needed - ironic and tripleo-ui] - Discuss at PTG
[ironic] https://bugzilla.redhat.com/show_bug.cgi?id=1362361
http://docs.openstack.org/developer/ironic-inspector/usage.html#discovery
this is finished and integrated with undercloud installation, it requires setting node-not-found-hook via undercloud.conf. Then each unknown node will be autoregistered with ironic during introspection
[tripleo-ui] investigate if it can be triggered explicitly from GUI by calling inspector/ironic API providing similar input as in undercloud.conf
additional info: http://paste.openstack.org/show/597939/
needs further discussion (needs API from hardware team - R
Nodes automatic profile tagging  [blueprint needed]amon Acedo PM)
[tripleo-ui] Enable introspection configuration by providing rules.json file which describes, ability to export/review current inspector rules
http://docs.openstack.org/developer/ironic-inspector/usage.html#rules
http://docs.openstack.org/developer/ironic-inspector/http-api.html#introspection-rules
[tripleo-common] possibility to pre-create introspection policy file (rules.json) from introspection data (requires mistral workflow)


(From UI DFG / Jiri Tomasek Etherpad

Comment 4 Anandeep Pannu 2017-05-03 14:11:53 UTC
For the UI the following will be needed
1. Ability to connect to the capabilities for auto-discovery provided by the H/W DFG
2. Auto-introspection of the nodes
3. Display of the nodes data (wireframe here https://openstack.invisionapp.com/share/247VLM4SB#/screens/164572258_2016-6-6_TripleO_UI32 ) 
4. Introspection and other steps in the workflow remain the same 

At this time we should still be able to use either auto-discover or upload nodes.json