Bug 1466873

Summary: [Intel OSP13][RSD] Discover and compose storage drives on Intel RSD nodes
Product: Red Hat OpenStack Reporter: Krish Raghuram <krishnan.raghuram>
Component: python-rsdclientAssignee: Nobody <nobody>
Status: CLOSED EOL QA Contact: Shai Revivo <srevivo>
Severity: high Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: apevec, bfournie, emacchi, jschluet, lhh, mburns, racedoro, srevivo
Target Milestone: z3Keywords: FutureFeature, OtherQA, Reopened, TechPreview, TestOnly, Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: python-rsdclient-0.1.1-1.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-10 17:19:22 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: 1510587    
Bug Blocks: 1414581, 1419948, 1422243    

Description Krish Raghuram 2017-06-30 15:31:40 UTC
Description of feature:
RSD platforms currently support the Redfish API, and are expected to soon support the Swordfish and Yang-to-Redfish APIs. Red Hat has already written a Redfish library (Sushy) to provide access from within OpenStack to the RSD platforms. Functionality is needed within OpenStack (eg. through the CLI), to view and manage the storage drives through the open APIs. Specifically:

-	discover and list RSD storage drives – PCIe devices 
-	IB and OOB discovery of SAS JBODs (iSCSI targets)
-	Allow composition of nodes with full drive PCIe devices.
-	Allow decomposition of nodes with erase and no erase option for data on drives
-	List storage drive metric

Version-Release number of selected component (if applicable):
OpenStack Client version (potentially) in OpenStack Queens release

2. Business Justification:
  a) Why is this feature needed?
     RSD is a new architecture that realizes an agile infrastructure where the hardware resources can be pooled according to application needs. It also enables a more easily scaled infrastructure, so CPU, memory, network and storage resources can be added as needed, without the need to do complete replacements of nodes
  b) What hardware does this enable?
   New platforms based on RSD architecture
  c) Is this hardware on-board in a system (eg, LOM) or an add-on card? 
  RSD nodes are disaggregated (CPU, memory, storage, accelerators etc.)
  d) Business impact? N/A
  
  e) Other business drivers: N/A

3. Primary contact at Partner, email, phone (chat)
   Priyank Durugkar - priyank.durugkar

4. Expected results:
- DC admin installs the undercloud
- Admin then uses the CLI to discover PCIe and iSCSI storage devices (along with other resources covered in other RFEs)
- Admin then composes a node on a RSD rack with the required PCIe and iSCSI storage resources
- TripleO then deploys the composed node in the overcloud
- Once a node is no longer needed, admin decomposes the node 

Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2017-06-30 15:31:44 UTC
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.

Comment 3 Krish Raghuram 2017-09-21 14:49:15 UTC
We've merged all the code into https://github.com/openstack/rsd-lib and https://github.com/openstack/python-rsdclient. We're now working on a final piece - Ironic drivers to recognize the remote storage attached to a composed node - and we're also setting up a CI/CD environment on an RSD rack to test and submit the Ironic changes. This is high priority for Queens release

Comment 5 Ramon Acedo 2017-10-19 10:52:18 UTC
Hi Krish, could you share the patches related to Ironic mentioned in comment #3?

We understand that this RFE will depend on adding the python-rsdclient to RDO and OSP, then finishing the work you mention with the Ironic to recognise the remote storage.

Adding it to OSP 13, pending the usual reviewing of dependencies, security, legal, etc. for adding python-rsdclient and its dependencies to OSP.

Comment 6 Krish Raghuram 2017-10-19 15:28:37 UTC
(In reply to Ramon Acedo from comment #5)
> Hi Krish, could you share the patches related to Ironic mentioned in comment
> #3?
> 
> We understand that this RFE will depend on adding the python-rsdclient to
> RDO and OSP, then finishing the work you mention with the Ironic to
> recognise the remote storage.
> 
> Adding it to OSP 13, pending the usual reviewing of dependencies, security,
> legal, etc. for adding python-rsdclient and its dependencies to OSP.

Ramon, here's been some conversation in Gerrit between Dmitry and our engineers on the Ironic driver. It looks like that driver enhancement may not be needed ie. the manual work-around to attach remote storage is fine. See https://review.openstack.org/#/c/506400/6

Comment 7 Ramon Acedo 2017-10-20 08:55:38 UTC
Hi Krish, if pythonrsd-client is capable of composing nodes and their storage, should we mark this BZ as a duplicate of BZ#1466874

Comment 8 Ramon Acedo 2017-10-20 10:13:58 UTC

*** This bug has been marked as a duplicate of bug 1466874 ***

Comment 9 Nate Potter 2017-10-20 16:52:08 UTC
Hi Ramon,

I don't think this is entirely a duplicate of 1466874, because it includes remote storage and PCIe discovery, i.e. the ability to figure out what resources you have available for storage when you go to add it at compose time. Also, PCIe device storage can be attached and detached on the fly to nodes that have already been composed, and is unrelated to the discovery and composition of nodes.

Comment 10 Ramon Acedo 2017-10-24 09:27:34 UTC
Hi Nate, thanks for your clarifications. Let's keep this RFE open to track the development and testing of the feature.

Could you please add the following information to this RFE:

- The patches in OpenStack Gerrit associated this work
- The test plan to verify that this feature works after its implementation

Comment 11 Nate Potter 2017-11-09 20:47:10 UTC
Hi Ramon, here are the relevant gerrit reviews:

https://review.openstack.org/#/c/491892/
https://review.openstack.org/#/c/496962/
https://review.openstack.org/#/c/502862/
https://review.openstack.org/#/c/499817/

The validation beyond in-tree testing will involve using an RSD hardware rack that we have available at Intel and running each relevant command through rsd-lib against it, including node composition with and without remote storage, discovery of storage elements and PCIe devices, and attaching/detaching PCIe drives to already composed nodes.

Comment 12 Ramon Acedo 2017-11-15 11:32:57 UTC
Hi Nate, thanks for the gerrit reviews.

Adding BZ#1510587 which requests the addition of rsd-lib and python-rsdclient as a dependency and they'll be necessary for testing.

Comment 17 Lon Hohberger 2018-07-23 10:34:41 UTC
According to our records, this should be resolved by python-rsdclient-0.1.1-1.el7ost.  This build is available now.

Comment 18 Sean Merrow 2018-08-16 20:56:53 UTC
Krish, this one is also ready for QA by Intel. Please post the results when complete.

Thanks,
Sean

Comment 19 Krish Raghuram 2018-08-24 16:56:53 UTC
(In reply to Sean Merrow from comment #18)
> Krish, this one is also ready for QA by Intel. Please post the results when
> complete.
> 
> Thanks,
> Sean

Sean, same response as the one for 1412053 - we don't test deployment on the RH OSP overcloud

Krish

Comment 27 Lon Hohberger 2023-07-10 17:19:22 UTC
OSP13 support officially ended on 27 June 2023