1. Description of feature: RSD Controller can help TripleO compose high performance nodes with NVMe drive pooling over PCIe. By composing such nodes, RH OSP end users can deploy high priority customer workloads on extremely efficient non-volatile storage backends used as ephemeral storage. Storage is available only for the life span of the node. NVMe storage is delivered back to the pool post-usage. Version-Release number of selected component (if applicable): TripleO version in OpenStack Pike 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? c) Is this hardware on-board in a system (eg, LOM) or an add-on card? 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 login to TripleO - Based on QOS policies, TripleO composes high performance (Xeon) RSD logical node with NVMe drive as ephemeral storage - Later end user uses this RSD logical node to host/run high performance workloads - Once end user finishes running the workload, TripleO deletes the node & NVMe resource is back in RSD pool as "available" Additional info:
Can we be more specific on what is the output of this RFE (is it role definition with default params?)? Isn't it only documentation effort in the end? Since the mechanism for such use-case is available. Is there missing some puppet modules / heat config? Who is expected to work on this feature? Who is expected to test it?
Hi Krish, Could you respond to the questions posed in comment #2? Thanks, Joe
(In reply to Joe Donohue from comment #3) > Hi Krish, > > Could you respond to the questions posed in comment #2? > > Thanks, > Joe We had put this in as a placeholder while still in internal discussion about what exactly needs to be done in TripleO. Please bear with us - should be able to get back in a couple of weeks
(In reply to Jaromir Coufal from comment #2) > Can we be more specific on what is the output of this RFE (is it role > definition with default params?)? Isn't it only documentation effort in the > end? Since the mechanism for such use-case is available. Is there missing > some puppet modules / heat config? Who is expected to work on this feature? > Who is expected to test it? We have provided capability to compose an RSD node with PCIe-attached NVMe storage in the RSDclient and RSDlib libraries to be used by OpenStack Client plug-ins (https://github.com/openstack/python-rsdclient and https://githib.com/openstack/rsd-client) We're now working on an Ironic plug-in driver to recognize the presence of this PCIe-attached storage, and hope to get it into Queens release Red Hat will need to test the ability of TripleO to provision an RSD node with this attached storage. A future enhancement will be to allow remote boot from this PCIe-attached storage
Krish, since the ability to compose and show RSD nodes with NVMe storage devices is done in the python-rsdclient and TripleO/director will be able to use these nodes as Overcloud nodes as done with any other type of hardware, what type of functionality is described here? In my view, it would be desirable that Ironic inspector can see these storage devices, would that be what's requested here? If that's the case, we could track this tests here. Could you have the workflow tested and reported here. If there are any gaps, we can track them here. This would be the workflow we envision: a. operator composes RSD logical nodes with NVMe storage (via the OSC python-rsdclient plug-in) b. operator registers nodes to TripleO/director using their Redfish interface c. operator uses root device hints to instruct TripleO/director to deploy Overcloud nodes' OS on the NVMe disks (provided there are more disks to install on other than the NVMe) c. operator deploys Overcloud on the composed RSD logical nodes Please, confirm if our understanding is right. Many thanks.
Adding needinfo to krish per comment#6
(In reply to Ramon Acedo from comment #6) > Krish, since the ability to compose and show RSD nodes with NVMe storage > devices is done in the python-rsdclient and TripleO/director will be able to > use these nodes as Overcloud nodes as done with any other type of hardware, > what type of functionality is described here? > > In my view, it would be desirable that Ironic inspector can see these > storage devices, would that be what's requested here? If that's the case, we > could track this tests here. > > Could you have the workflow tested and reported here. If there are any gaps, > we can track them here. > > This would be the workflow we envision: > > a. operator composes RSD logical nodes with NVMe storage (via the OSC > python-rsdclient plug-in) > > b. operator registers nodes to TripleO/director using their Redfish > interface > > c. operator uses root device hints to instruct TripleO/director to deploy > Overcloud nodes' OS on the NVMe disks (provided there are more disks to > install on other than the NVMe) > > c. operator deploys Overcloud on the composed RSD logical nodes > > Please, confirm if our understanding is right. Many thanks. Yes, this is correct, Ramon. The basic work in being able to compose nodes with PCIe-attached NVMe drives is already there in rsdlib/rsdclient. Just need to test as you've described
Thanks. Adding BZ#1466874, which tracks the inclusion of rsd-lib and python-rsdclient, as a dependency. When the packages are ready and you can test it, please, post here the test plan and results.
According to our records, this should be resolved by python-rsdclient-0.1.1-1.el7ost. This build is available now.
Krish, this is ready to be QA'd by Intel. It is in build python-rsdclient-0.1.1-1.el7ost or later. Please post results when complete. Thanks, Sean
(In reply to Sean Merrow from comment #17) > Krish, this is ready to be QA'd by Intel. It is in build > python-rsdclient-0.1.1-1.el7ost or later. Please post results when complete. > > Thanks, > Sean Sean, we don't have a test setup for RH OSP, and thus cannot do QA on this. It is our expectation that you will confirm that RH Director is able to deploy nodes on the overcloud with NVMe storage attached, and initiate boot sequence to bring them up. Our work is restricted to testing & verifying that the nodes can be composed with NVMe storage and registered with OpenStack Ironic in the undercloud Krish
OSP13 support officially ended on 27 June 2023
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days