Hide Forgot
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@intel.com 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:
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
We've added iSCSI and PCIe-attached NVMe support so far. Links: https://blueprints.launchpad.net/python-rsdclient https://review.openstack.org/#/c/491892/ https://review.openstack.org/#/c/496870/ https://review.openstack.org/#/c/497706/
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
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.
(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
Hi Krish, if pythonrsd-client is capable of composing nodes and their storage, should we mark this BZ as a duplicate of BZ#1466874
*** This bug has been marked as a duplicate of bug 1466874 ***
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.
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
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.
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.
According to our records, this should be resolved by python-rsdclient-0.1.1-1.el7ost. This build is available now.
Krish, this one is also ready for QA by Intel. Please post the results when complete. Thanks, Sean
(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