Red Hat Bugzilla – Bug 1468011
[Intel OSP13] Sushy driver extensions for RSD storage (Swordfish)
Last modified: 2018-01-04 13:33:30 EST
Description of feature:
The existing Sushy driver used by Ironic to control RSD nodes should be extended to support the emerging Swordfish API for storage being worked in the Redfish community
Version-Release number of selected component (if applicable):
Sushy driver 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)
Mrittika Ganguli - firstname.lastname@example.org
4. Expected results:
- Admin composes a node on a RSD rack with the required storage resources
- TripleO then deploys the composed node in the overcloud
- Ironic or Cinder (or other OpenStack module like Swift) interfaces with the RSD node using the Sushy driver extension for storage
Thanks for your request. Ironic does not manage storage stuff directly, we only call into Cinder for that. We don't interface with Swift for vendor-specific stuff at all. I'm moving this RFE to a more generic component for evaluation by storage folks.
Is this RFE still relevant?
If it is, is there any code upstream to track? By the description, it looks like this is something the python-rsdclient would be able to do using rsd-lib by interacting with the RSD APIs instead of with Sushy. Is this assumption right?
Adding need_info for Krish per comment #2.
(In reply to Ramon Acedo from comment #2)
> Hi Krish,
> Is this RFE still relevant?
> If it is, is there any code upstream to track? By the description, it looks
> like this is something the python-rsdclient would be able to do using
> rsd-lib by interacting with the RSD APIs instead of with Sushy. Is this
> assumption right?
Yes, that's correct. We can push this out to RH OSP14. It will become relevant when we want to compose nodes with storage volumes, and attach/detach volumes later. We expect that to become part of a future spec
Thank you. Please, let's submit the RFE for OSP 14 then, along with details like the spec to be written.
Re-opening this RFE, Intel is planning to implement this feature for OSP14.
Answering a previous question, this will be implemented with rsd-lib. The plan is to support the subset of Swordfish applicable to RSD's Storage Service.